Call openReport when parent report is mssiing

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/34346
PROPOSAL: https://github.com/Expensify/App/issues/34346#issuecomment-1934568395
Tests

Create a new account, lets call it Account A
Create another new account, account B
Send an IOU from account A to account B and go to IOU details page and copy the URL
Sign in with account B
Navigate to the copied URL on step 3
Verify that the parent report link is exists in header

[x] Verify that no errors appear in the JS console

Offline tests

N/A
QA Steps

Same as in the Tests section.

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari
https://github.com/Expensify/App/assets/46921547/5681aa71-ac2f-4942-bd55-702c8dc6d494

MacOS: Desktop

@s77rt The changes are not platform specified and those are functional and not affect to UI.  Can I add only one video ?

Looks we have more bugs to cover

Initially I'm getting the not found view
After reload, the [Deleted message] title can be briefly seen
Money request info is missing and had to reload another time to get the correct view

https://github.com/Expensify/App/assets/16493223/db09a1a1-3bd6-456b-a5f3-976c4856b47a

Ok . I will work on it

I think the ReportScreen component should be updated and use withReportOrNotFound

I don't see how would that fix the bug?

It does not reproducible in last main

Can you please merge main to this PR

The root cause is the memoization of component

Memorization being the root cause would make sense (didn't check in depth) but we should not render every report action just because the parent action is different (especially since many report actions have no relation with the report's parent action)

I think the ReportScreen component should be updated and use withReportOrNotFound

I don't see how would that fix the bug?

Doesn't it requests the report when it doesn't find it in Onyx?

The root cause is the memoization of component

Memorization being the root cause would make sense (didn't check in depth) but we should not render every report action just because the parent action is different (especially since many report actions have no relation with the report's parent action)

Then we can use below comparison
ReportActionsUtils.isTransactionThread(ReportActionsUtils.getParentReportAction(prevProps.report)) !== ReportActionsUtils.isTransactionThread(ReportActionsUtils.getParentReportAction(nextProps.report))

Seeing that we have more bugs to deal with than expected I think it's best to rethink how we can fix those bugs on the drawing board i.e. the github issue

@shahinyan11 I have replied on the linked issue. Can you please close this PR and post new proposals on the issue covering all the found bugs

@shahinyan11 I have replied on the linked issue. Can you please close this PR and post new proposals on the issue covering all the found bugs

Are you able to reproduce [Deleted message] after las updates ?

@shahinyan11 Just retested and I didn't get the [Deleted Message| bug but the rest are still reproducible
https://github.com/Expensify/App/assets/16493223/b3a46c73-e104-4694-832d-d2e53bfbf820

@shahinyan11 Usually we treat each bug separately and in parallel but here we can't fix the wrong header bug without fixing the not found view bug first. They do not have same root cause so I guess the proposals should outline each bug independently. We can open another issue for the not found view bug but since they have the same reproduction steps it may be good to consolidate them (as long as they are not too complex).

@shahinyan11 Can you please close this PR


Does it work for Meteor 1.2

Hi,
I tried Komposer version 1.3.1 with Meteor 1.2 , but couldnt get it to work in a consistent manner.
A subscription would stop "on-its-own",
The Tracker computations state had first-run = true on multiple runs
putting my function inside a simple Tracker.autorun worked and generated consistent results
Thanks,
Shay

Not tested with it. How do you  use it? With browserify?
Can I have some sample app?

Yes , I used browserify
Komposer = require('react-komposer');
the code was identical to the meteor sample from the docs :
function composer(props, onData) {
if (Meteor.subscribe('posts').ready()) {
const posts = Posts.find().fetch();
onData(null, {posts});
};
};
I would then notice that after the subscribe became ready , it would get removed, and any updates to the collection were not visible because the subscription was no longer active
I assume that the collection was un-subscribed due to  Autorun block closing , but couldn't see what caused it to close.
According to Auto-run docs if its the same subscription it should not get destroyed and recreated.

I had a similar issue using Meteor 1.2.
When I had composeWithTracker nested under own HOC that used ReactMeteorData the subscriptions would sometimes get stopped. It would consistently happen when I opened a new browser tab going to the site.

My issues seem to be resolved with some refactoring to my codebase. I don't think the issue was related to react-komposer.

OK I'm actually still seeing this issue. Subscriptions will randomly stop when using composeWIthTracker.

I've confirmed that using compose() with a Tracker.autorun inside of it works fine.
Using compseWithTracker, which looks like it stops the autorun block on each cycle and then restarts it is causing issues with my subscription getting stopped and started and constantly reloading data.

More testing and I think I have come up with the real culprit. When I put Meteor.user() in a compseWithTracker composed on top of another HOC (as in the user gets fetched and passed into the next component to fetch data) I see a lot of issues my subscription constantly re-running. I'm not sure what would be causing Meteor.user() to change so frequently but it seems that it's constantly causing props changed to be fired.

Hello, I faced with this issue on with the latest Meteor (1.3-beta-12), and it happens all the time within one of the routes.
repo: here
How to reproduce:

This is reaction. You'll need to login as admin. Admin login/password will be visible in console after meteor (no need to do anything else)
after login, go to /shop route, you should see one default product.
step into it. Bug occurs here.

Within composer function you can check Products and Media collections by ReactionCore.Collections.Products.find() and ReactionCore.Collections.Media.find(), but after you step out this function, both collections become unreachable.

Hi, @arunoda, could you, please, take a look on this?

@newsiberian Could you send me a small repo with the bug. It's hard for me to debug this big app :)
@clayne11 can we have a sample repo. I'm keen to find this and fix it.

@arunoda, I'm sorry, but can't. I was tried to reproduce this on simple app before publishing this one, and on a simple app komposer worked as expected.

I seem to have solved the issue. I never had any problem with the ReactMeteorData mixin so I looked at how that was constructed to get some insight.
They wrap their Tracker.autorun in a Tracker.nonreactive block. By doing this, I was able to fix all of the issues I was having with composeWithTracker.
The new composeWithTracker function looks like this:
export function composeWithTracker(reactiveFn, L, E, options) {
  const onPropsChange = (props, onData, context) => {
    let trackerCleanup;
    const handler = Tracker.nonreactive(() => {
      return Tracker.autorun(() => {
        trackerCleanup = reactiveFn(props, onData, context);
      });
    });

    return () => {
      if (typeof (trackerCleanup) === 'function') {
        trackerCleanup();
      }
      return handler.stop();
    };
  };

  return compose(onPropsChange, L, E, options);
}

I'm not 100% sure that the autorun is getting cleaned up properly though, however this has fixed all of my issues with data not being fetched properly and subscriptions getting stopped.
I put a print statement inside the inner Tracker.autorun to print the computation._id and I never saw the same _id getting printed after the component had been unmounted.
I'm going to submit a PR to with my fix and I'd like to hear your feedback on if you think I am cleaning up the autorun properly.


Add "Debug Shiny App" command to editor run menu

Anytime you see "Run Shiny App" on the editor run menu, you should now also see "Debug Shiny App" right below it. This will launch the Python debugger on the currently focused Shiny app file, using a random-ish port, and launch the Simple Browser when the app is ready.

Wait, sorry, there’s some extra code in this PR that I need to remove

There's an advanced debugger config flag justMyCode which I've hardcoded to true--this means that breakpoints in third party packages won't be respected. LMK if you disagree.

Just to double check...
This means that if a user sets a breakpoint in their own personal code, then the breakpoint will work. But if the user sets a breakpoint within py-shiny, then the py-shiny breakpoint will not be found?

^^ If the user is still able to debug py-shiny, then I'm ok with justMyCode: True. (No real need to debug into the standard libraries)

Oh, I'm wrong about the behavior of justMyCode. It also prevents you from stepping into anything that's not your code. justMyCode: true is the default behavior in VS Code. Maybe this needs to be a setting?

If it can easily be a setting, that'd be great!
I'm ok with the default being true.

I added it as a setting. I will say, now having played with it both ways, justMyCode is definitely the correct default. With it set to False, you step into the underlying Python dunder method for every index operation, list comprehension, etc.

Up to you if you'd like to keep the setting. I just want app authors to be able to get to the underlying shiny code.
Yes, going into list functions doesn't seem right for shiny debugging


Can we avoid needing Commands installed in startup project for Full .NET apps?

Currently we require commands to be installed in the startup project, this is nasty from an architecture perspective though. I'm guessing we only introduced this requirement for xproj?
PM> Add-Migration NextMigration
Cannot execute this command because Microsoft.EntityFrameworkCore.Commands is not installed in the startup project 'src\RocketProfiler.UI'.

It think this may have always been the case. If I remember right, VS wouldn't copy M.EFC.Commands.dll to the output directory if it was only transitively referenced.

Remarking for triage: this can wait until after RTM.

Scope question: are we trying to do this just for csproj/packages.config projects?

Any progress we can make would be good, if csproj is easier then that would still be a win. BTW I think it would be really good to relax this restriction... but I also don't think it's a ship stopper for tooling RTM. So I think the decision can take into account how messy the implementation is 😄

Here is my thinking. After #5334, here is the tooling in layers of dependency:

.Tools.VisualStudio/ .Tools.DotNet  = init.ps1 and dotnet-ef
.Design = OperationExecutor, the version-resilient design-time "entry-point" into the app
.Relational.Design = other design-timey stuff.
.Relational and below = the runtime stuff

The tools layer is the funny bit. .Tools.VisualStudio "floats" across all projects in a solution because PMC cmdlets are solution-global, and the .Tools.DotNet is disconnected from the app's "dependencies". But both still need the next layer down is why our tools require installing (what used to be .Commands) .Design.
To ease the restrictions, we could:

Squash design layers down. We could squash the code in .Design down into .Relational.Design. I'm not sure the separation is as important post #5334.  (I like this idea most)
Make the tools layer carry the next layer down with it. Tools copy the design dll's to the right place before running and cleans up after
Squash design into runtime. We could be even more aggressive and push it all into .Relational. Downsides: violates our pay-for-play ideals, increases binary size. Upsides: tools will basically work anywhere EF runtime is installed. (I like this idea least)

I still don't think there's anything we can do here. NuGet/MSBuild won't copy transitive dependencies to the output directory, and the best workaround is to install them directly into the startup project.

Should we just close this one then? I don't think we need to spend a lot of time trying to work around it, I just raised it as something that would be good to make easier if we could.

I vote to close, yes.

Sold! 🔨


core: Update azure.yaml.json for remoteBuild

This adds the remoteBuild configuration knob which was added in azure/azure-dev#4161 to our schema for azure.yaml.
Fixes #4353

/check-enforcer override


Table Splitting Example creates a Order_Status column in the database

Running the Table Splitting Example creates a Order_Status column which isn't intuitive. I don't know if this is the expected output because for existing databases we need to create [EntityName_BaseColumnName] for each column from the Base Entity class to use this approach which isn't feasible for many applications. Can you clarify if this is how this should work?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: c847da37-ca7d-1c42-8acf-405167085d27
Version Independent ID: bd4fe1c7-514d-cfb1-d975-4096306b06e9
Content: Table Splitting - EF Core
Content Source: entity-framework/core/modeling/table-splitting.md
Product: entity-framework
Technology: entity-framework-core
GitHub Login: @AndriySvyryd
Microsoft Alias: ansvyryd

@AndriySvyryd Yes, that works.
It would be more intuitive when someone adds .HasBaseType((string)null) to the entity then EF Core automatically stops appending the Base Class to the properties of the Entity.
I don't know if this is the correct place to suggest this.

@ajcvickers I cloned this repo and ran the code from the Table Splitting Sample.

@abhishek-raj It would be best to open a new issue on https://github.com/aspnet/EntityFrameworkCore/issues to request that the same CLR properties are mapped to the same columns by default.


Migrate k8s to kubernetes/client-go

The official k8s go client has now its own repository and seems a lot more useful than the old one (https://github.com/kubernetes/kubernetes/issues/11606): https://github.com/kubernetes/client-go
It's time to migrate :)

the size of the client still ugly :/

It's large, but handles all known failure cases with the apiserver. I don't think traefik's client is correct. Also, it uses protobuf now which is much more efficient.

Ah I see this is a duplicate of an issue that covers many more of the problems, ignore me :)

This should have been closed when #836 was merged


Smart switches state weird on, off, on, behaviour

Describe the bug
(CFR: VIDEO)
Since recently I'm experiencing a weird behaviour when I toggle a Tuya smart switch in HomeAssistant.
When toggled, it will jump to the opposite state .. then after a second back to the previous state .. then after another second to the correct state again. Also the color of the state is only correct when this sequence of events is finished.
Between the moment I click the toggle and the end of the sequence of this weird behaviour I can't do anything but wait and hope the state repairs itself.
I tested toggling the switch in the Tuya app AND in the Google Home app, but there this is working as expected.
Expected behavior
The toggle, when toggled to switch to the correct opposite state instantly, without weird behaviour.
Video
In this video, I'll toggle 4 entities:
Bedroom light: None-Tuya Zigbee light
Nightstands: None-Tuya Zigbee light
Bathroom light: Tuya Wifi switch
Toilet light: Tuya Wifi switch
(Just to show the difference in what is, to me, right and faulty behaviour)
https://user-images.githubusercontent.com/4070167/201656061-ce7535d6-d136-47ba-b59d-1abcd3c38cc5.mov
The HA logbook just show the turn_on and turn_off actions performed by toggling the switch (as seen in the video).
It doesn't show anything like the switch going on-off-on-... or off-on-off-...
Which makes me think its an issue either in the Tuya-HA-integration, or in HA itselfs. (But ofcourse, I can't be sure)

I thought it also could have anything to with the Device Status Notification service, but I'm assuming this still works since the end state is correct.
Home Assistant Version

2022.11.2

Tuya integration Version

Up-to-date

If any more info is required, let me know!

I've noticed today that the issue went away the same way it appeared. Just like that.
I'm guessing there was an issue with one of the Tuya services.
Happy to close this one since it seems not to be an issue with the integration! 👌


Version Control

Hi @MileyHollenberg,
Thanks for making this awesome UPM package. I'm the creator of the OpenUPM platform, an open-source UPM registry, and continuous build service based on Git tags. It's hosting more than 300+ open-source UPM packages at the time of writing.
To make your package available on the platform you need create one GitHub release v1.0.0 (which created a Git tag) based on the master branch. Then you can submit the package here.

Hey @favoyang ,
Thanks! I've heard of OpenUPM before but haven't used it myself yet. I did a quick check and saw that the dependent package is also available there so it wouldn't be too much work to get it published on OpenUPM as well, I'll have a look at this this weekend.
Quick question beforehand for which I am assuming the answer will be yes, does OpenUPM properly support multiple dependencies? I tried to get this to work with the current Package Manager from Unity but this is something the team is still working on for Github projects which is why I currently have the setup instructions in the Readme
Greets,
Miley

Hmm, it seems like the Toolbar extender isn't fully available yet, it says it has no install available yet, https://openupm.com/packages/com.marijnzwemmer.unity-toolbar-extender/
Since there's an open issue on his package already for this I'll let him know, once that's taken care of I can add OpenUPM support for this package as well :)

Thanks for the quick reply.
To support custom dependencies, you need add all dependencies to scopes field. OpenUPM-CLI provides such feature by resolving dependencies recursively.
openupm add pkgname

I was able to add the dependency through regular git and it seems like OpenUPM is supporting it as is, the release (v1.0.1) is now live so this issue can be closed :)


LC0005 field datatype with length

Incorrectly cased field data types with length e.g. text[10] will not give LC0005 warning.
    field(2; Subject; text[10])
    {
        DataClassification = CustomerContent;
    }
    field(3; Body; coDe[10])
    {
        DataClassification = CustomerContent;
    }

This should now be resolved in the release version of v0.30.25 of the LinterCop.


Add selection center rotation and scaling

PR Details
Adds rotation and scaling from the center or from the last selected object
Description
You can now scale from the center from a selection as well as transforming away from the center rather than from the origin of each object. The selection can also be rotated from the center rather than only the last selected object.
Related Issue
#488
Motivation and Context
Sometimes it makes more sense to scale from the center rather than the last selected object. For example, something that takes up multiple objects like a room would be hard to scale otherwise.
Types of changes

[ ] Docs change / refactoring / dependency upgrade
[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

[ ] My change requires a change to the documentation.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Hey, thanks a bunch for this PR @nesrak1
I found a couple of things to fix/clarify, I'll list them below and in review.
Scaling down doesn't seem to work at the moment, is this PR ready yet ? If it isn't please mark this PR as WIP and I'll come back to it once it isn't, thanks !

I already had these fixes but forgot to commit, sorry!

Scaling negative works which may or may not be a good thing, since it seems to break lighting but can also flip the model.

It's quite alright :)
Doesn't quite seem to work correctly if object don't have zeroed rotation / are inside parents

@nesrak1 just checking, is the PR ready/finished?

Should be ready unless you find another bug I haven't seen yet

Ran a few tests and noticed some issues.
Here's what happens when I:

Create entity with some rotation (i.e. 90 degrees Y axis)
Put a sphere as children of this entity with some translation (i.e. Z = 2)

The gizmo is not at the expected location:

Here is what's expected:

@nesrak1 Hey, this PR hasn't been very active those past few months, are you still working on this or should we close this off ? If someone wants to take it from here please do so but leaving this active might prevent other people from tackling this issue.


UI and QOL tweaks for contacts view.

it says tweaks, but I understand this is a pretty drastic UI redo, thoughts? Each button will correctly open with autoLinker

That looks really nice! does it always only display the top 2 contact links?

Yeah so it will return as many as the first 3 links in their card.

I like it, looks clean.
If I can be nitpicky, bigger lineweight on the separation between each card and also the search bar would be good. As well as cutting the name size down, even "Dennis Reynolds" is being pushed to 2 lines and that's not a particularly long name.

Valid comments, will make those changes


custom_data field for Commands

Currently, Commands are relatively limited in the amount of metadata you can provide to them.
There's the help-fields and the category, but both of those have specific usecases and are limited in what they can and should store.
It would be useful to be able to store arbitrary additional information together with the command declaration, thus allowing users of poise to implement their own system for keeping track of things such as specific permission requirements, additional help-data (i.e. usage examples, etc) and many other things.
After a short discussion of this in the serenity discord server, we came to the conclusion that it'd make sense to provide a custom_data field in the poise::command macro, which could store any user-provided struct together with the command, via a Box<dyn Any>.
I.e.:
#[poise::command(
  slash_command,
  custom_data=r#"CmdData { perm_level: PermissionLevel::Helpers, example: "/mute someguy 10m" }"#
)]
pub async fn mute(...) -> Result<()> {
...
}

Implemented in 8f49befaa34e9c38b003ee64ea95d727a9bcaff9


CreateCompatibleDC returns HDC but it should return DeleteDCSafeHandle

Referencing Microsoft.Windows.CsWin32 0.1.432-beta only.
In 0.1.422-beta, I could dispose created DCs easily. Now, it looks like I need to declare DeleteDCSafeHandle myself to safely deal with owning this handle.

I can see this repro. Thank you for reporting.

Evidently fixed by 1ef99357eb93fd (v0.1.433-beta).

Why the weird naming? DeleteDCSafeHandle. Why not HDCSafeHandle?

@gavin-williams The SafeHandle names are not human crafted. They are based on the name of the method that releases the handle.


what is the default legato behavior?

If you don't specify anything, what is supposed to happy when you are playing one voice, and the pitch changes? It seems that what sforzando does is turn off the currently sounding region "very quickly", the fades in the new one with what seems to be an attack of about 10 ms.
I know there are very elaborate ways to specify legato behavior, and I have looked at the tutorial (which, frankly, I don't understand). But this defulault behavior seems undocumented.

Tested that setting group and off_by to add self-muting doesn't do anything different to attack and release envelopes, and uses the default values in Sforzando, same as for non-legato notes. Added this at the start of the legato tutorial.

so if attack and release are both very long, and there is no off_by specified, and the pitch changes on a channel without the gate changing, then the voice is supposed to fade out with the long release time specified, then switch pitch and start fading in with the long attack time specified? I don't think that's what sforzando does, but I could be wrong.

You do need off_by (or polyphony=1 set for the group) to get legato behavior, so with no off_by specified you will just get both notes playing at once. But if off_by is set to the same number as group, which is the typical thing to do in legato instruments, then as far as I understand, the "old" note fades out with release time being the fadeout duration. As soon as it starts fading out, the new note starts fading in. So, there's overlap.
I haven't done any detailed testing to investigate how this really behaves, but it seems to work like that. I've done some choirs with the fade times probably being around a half a second, so pretty long.

Hmm... I'll have to play around and see if I can find what I was asking about... Probably I was confused.


Integrate with Square mobile apps for in-person card payments

Only allow credit card transactions

@JoshOldenburg has an iPhone for development.

For reference, the Square Android and iOS apps communicate differently with web apps for some reason. The flow is the same but data structures and error codes vary somewhat.


Create a real pass

This code works for generic passes which are not an option when you create a real pass from google wallet api.
Did anyone find the code and json to test a real gift card or other passes?

If I understand you correctly you want to redesign your card? I just called the current implemented json with this function:
const classId = '1234567-xxx-xxxx-xxxxxxxxx; // that one you got from the test account
async function getGenericClass(req, res) {
  const credentials = require(serviceAccountFile);

  const httpClient = new GoogleAuth({
    credentials: credentials,
    scopes: 'https://www.googleapis.com/auth/wallet_object.issuer'
  });

  objectResponse = await httpClient.request({ url: "https://walletobjects.googleapis.com/walletobjects/v1/genericClass/" + issuerId +'.'+ classId, method: 'GET'});

  console.log(objectResponse.data)
  res.send( objectResponse.data );
}
//...
app.get('/googlegetclass', getGenericClass);
//....

now you can edit the original pass and suit it to whatever you want.
after that, you have to change the classId const in your code to whatever suits you. like "my-first-pass" and run this function to upload your layout. keep in mind that for new passes you should also use your classId.
const classId = 'my-new-class-id';
async function createGenericClass(req, res) {
  const credentials = require(serviceAccountFile);

  const httpClient = new GoogleAuth({
    credentials: credentials,
    scopes: 'https://www.googleapis.com/auth/wallet_object.issuer'
  });

  const objectPayload = require('./google_generic-pass_class.json');
  objectPayload.id = `${issuerId}.${classId}`;
  objectResponse = await httpClient.request({ url: "https://walletobjects.googleapis.com/walletobjects/v1/genericClass/", method: 'POST', data: objectPayload});

  console.log(objectResponse)
  res.send( objectResponse );
}
// .....
app.get('/googlecreatclass', createGenericClass);
// ....

I've wrote a small application to manager generic google wallet classes. Take a look at here. The program can also run as a docker container, if you have docker installed simply type..
docker run -it -p 3000:3000 tuttas/googlewalletclassmanager

Hello,
It looks like this issue hasn't been updated in a while. If you're looking for sample code to create Google Wallet passes of different types, please refer to the google-pay/wallet-samples repository. There you will find examples for creating pass classes and objects of multiple different types and in different programming languages.
I hope this helps! If you run into any trouble please open an issue in that repo and we will help out.

Hello, I am struggling to design my own pass so I have a few more questions on this topic. I am running the codelab with a generic pass and everything works fine. How should I modify the code to include the functions mentioned above? The code doesn't work if I exclude the app.post('/', createPassAndToken); part. I also often get a Default value for LocalizedString cannot be empty error. Sorry if it's some basic knowledge, I'd be really glad if you could help me.

Hello, I am struggling to design my own pass so I have a few more questions on this topic. I am running the codelab with a generic pass and everything works fine. How should I modify the code to include the functions mentioned above? The code doesn't work if I exclude the app.post('/', createPassAndToken); part. I also often get a Default value for LocalizedString cannot be empty error. Sorry if it's some basic knowledge, I'd be really glad if you could help me.

Sadly I can't help you with those error messages. The two functions above show how you can download the sample pass (function: getGenericClass). if you store the output of that function to "./google_generic-pass_class.json" then you are able to use the second function (createGenericClass)  to upload this json as a new pass. So inside this json you can make modifications on how the pass should look like. Both are additional to the sample code.

Thank you for the fast reply. Should the additional functions be called before or after app.post('/', createPassAndToken); ?

Before to create your used pass. It is more like two utility functions which should not be exposed to "users" and are just for creating everything around.


Can't Delete image in Markdown editor

Bug Report 🐛
See this Loom video where I had tried to delete the text and image but the image was not able to delete
Loom link : https://www.loom.com/share/558b1ef9151c45e59de3962ec62def4b
Or see this video:
https://user-images.githubusercontent.com/58624108/112434714-e64fbd00-8d69-11eb-9937-01f9828cf010.mp4
Expected Behavior
By selecting the image and then clicking the delete/backspace image should get deleted
Current Behavior
By selecting the image and then clicking the delete/backspace image was not deleted
Possible Solution

Steps to Reproduce

Go to markdown editor (https://ap-web-components.netlify.app/?path=/story/markdown-editor--demo)
Try to add an image or use an existing sample image
Select the image and try to delete it with the delete/backspace key

Context (Environment)

Desktop

OS: Windows 10[e.g. macOS]
Browser: Chrome[e.g. Chrome, Safari]
Version: 89.0[e.g. 0.22.15]

Detailed Description

Possible Implementation

I would like to work on this issue.

@d-e-v-esh, I was willing to work on this but as I'm currently busy with my end-semester examinations, you may take this 👍🏻

@Aniruddha-Shriwant My exams just got finished so I'd be happy to work on this. Thanks man 👍

I would like to work and fix this issue. Can you guide me through how to contribute

@dezfuture I have started working on this issue. You can look for more issues or find what you like from the list.

okay np

@irmerk
Since the issue was open for many days with no activity on it. I have created a PR that might be able to solve the issue.


[Feature] Add Kubernetes manifest validation in pre-commit.

Why are these changes needed?
To resolve issue #2254, the absence of a Kubernetes manifest validation process caused the errors listed in the issue when deploying the Helm Chart. During validation, I also discovered that running helm template ./ in helm-chart/ray-cluster resulted in .template.spec.containers.ports being set to null (which should either be omitted or set to an empty list []). I have fixed this issue as well.
Related issue number
Closes #2254
#2174
#2239
Issue Reproduction and Manual Validation Results
I reproduced the error from Issue #2174. Running helm template ./ within the helm-chart/ray-cluster directory generates the following output:
ray-cluster $ helm template ./
---
# Source: ray-cluster/templates/raycluster-cluster.yaml
apiVersion: ray.io/v1
kind: RayCluster
metadata:
  labels:
    helm.sh/chart: ray-cluster-1.1.0
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/managed-by: Helm
  name: release-name-kuberay

spec:
  headGroupSpec:
    serviceType: ClusterIP
    rayStartParams:
        dashboard-host: "<IP_ADDRESS>"
    template:
      spec:
        imagePullSecrets:
          []
        containers:
          -
            volumeMounts:
            - mountPath: /tmp/ray
              name: log-volume
            name: ray-head
            image: rayproject/ray:2.9.0
            imagePullPolicy: IfNotPresent
            resources:
              limits:
                cpu: "1"
                memory: 2G
              requests:
                cpu: "1"
                memory: 2G
            securityContext:
              {}
------>     env:

        volumes:
          - emptyDir: {}
            name: log-volume
        affinity:
          {}

        tolerations:
          []
        nodeSelector:
          {}
      metadata:
        annotations:
          {}
        labels:
          helm.sh/chart: ray-cluster-1.1.0
          app.kubernetes.io/instance: release-name
          app.kubernetes.io/managed-by: Helm

  workerGroupSpecs:
  - rayStartParams:
      {}
    replicas: 1
    minReplicas: 1
    maxReplicas: 3
    numOfHosts: 1
    groupName: workergroup
    template:
      spec:
        imagePullSecrets:
          []
        containers:
          -
            volumeMounts:
            - mountPath: /tmp/ray
              name: log-volume
            name: ray-worker
            image: rayproject/ray:2.9.0
            imagePullPolicy: IfNotPresent
            resources:
              limits:
                cpu: "1"
                memory: 1G
              requests:
                cpu: "1"
                memory: 1G
            securityContext:
              {}
------>     env:

        volumes:
          - emptyDir: {}
            name: log-volume
        affinity:
          {}

        tolerations:
          []
        nodeSelector:
          {}
      metadata:
        annotations:
          {}
        labels:
          helm.sh/chart: ray-cluster-1.1.0
          app.kubernetes.io/instance: release-name
          app.kubernetes.io/managed-by: Helm

After validation, the following output is generated:
stdin - RayCluster release-name-kuberay is invalid: problem validating schema. Check JSON formatting: jsonschema: '/spec/workerGroupSpecs/0/template/spec/containers/0/env' does not validate with file:///tmp/tmp.QsaaVEezYn/raycluster_v1.json#/properties/spec/properties/workerGroupSpecs/items/properties/template/properties/spec/properties/containers/items/properties/env/type: expected array, but got null
Summary: 1 resource found parsing stdin - Valid: 0, Invalid: 1, Errors: 0, Skipped: 0

If we consider the case mentioned earlier where .template.spec.containers.ports is set to null:
ray-cluster $ helm template ./
---
# Source: ray-cluster/templates/raycluster-cluster.yaml
apiVersion: ray.io/v1
kind: RayCluster
metadata:
  labels:
    helm.sh/chart: ray-cluster-1.1.0
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/managed-by: Helm
  name: release-name-kuberay

spec:
  headGroupSpec:
    serviceType: ClusterIP
    rayStartParams:
        dashboard-host: "<IP_ADDRESS>"
    template:
      spec:
        imagePullSecrets:
          []
        containers:
          -
            volumeMounts:
            - mountPath: /tmp/ray
              name: log-volume
            name: ray-head
            image: rayproject/ray:2.9.0
            imagePullPolicy: IfNotPresent
            resources:
              limits:
                cpu: "1"
                memory: 2G
              requests:
                cpu: "1"
                memory: 2G
            securityContext:
              {}

        volumes:
          - emptyDir: {}
            name: log-volume
        affinity:
          {}

        tolerations:
          []
        nodeSelector:
          {}
      metadata:
        annotations:
          {}
        labels:
          helm.sh/chart: ray-cluster-1.1.0
          app.kubernetes.io/instance: release-name
          app.kubernetes.io/managed-by: Helm

  workerGroupSpecs:
  - rayStartParams:
      {}
    replicas: 1
    minReplicas: 1
    maxReplicas: 3
    numOfHosts: 1
    groupName: workergroup
    template:
      spec:
        imagePullSecrets:
          []
        containers:
          -
            volumeMounts:
            - mountPath: /tmp/ray
              name: log-volume
            name: ray-worker
            image: rayproject/ray:2.9.0
            imagePullPolicy: IfNotPresent
            resources:
              limits:
                cpu: "1"
                memory: 1G
              requests:
                cpu: "1"
                memory: 1G
            securityContext:
              {}
------>     ports:
              null

        volumes:
          - emptyDir: {}
            name: log-volume
        affinity:
          {}

        tolerations:
          []
        nodeSelector:
          {}
      metadata:
        annotations:
          {}
        labels:
          helm.sh/chart: ray-cluster-1.1.0
          app.kubernetes.io/instance: release-name
          app.kubernetes.io/managed-by: Helm

After validation, the following output is generated:
stdin - RayCluster release-name-kuberay is invalid: problem validating schema. Check JSON formatting: jsonschema: '/spec/workerGroupSpecs/0/template/spec/containers/0/ports' does not validate with file:///tmp/tmp.CnlCCHOuhb/raycluster_v1.json#/properties/spec/properties/workerGroupSpecs/items/properties/template/properties/spec/properties/containers/items/properties/ports/type: expected array, but got null
Summary: 1 resource found parsing stdin - Valid: 0, Invalid: 1, Errors: 0, Skipped: 0

Checks

[x] I've made sure the tests are passing.
Testing Strategy

[x] Unit tests
[x] Manual tests
[ ] This PR is not tested :(

cc: @MortalHappiness, @kevin85421

Follow-up PR: Also validate RayJob and RayService

@LeoLiao123 can you open an issue to track the progress?

@kevin85421 Oops I didn't notice that. Thanks.


Update checker prompts to update to Beta and Alpha versions

The Update checker will prompt for an update if it is newer than the current mod version, even if it is a Beta or Alpha version.
It should either inform only about the stable version or clearly state that it is a Beta or Alpha version.

It also happens with other mods such as Sodium Extra.


feat: Add TestSequenceDiagram annotation

What this PR changes/adds
This PR adds the TestSequenceDiagram annotation, that allows to input a string that contains a sequence diagram in the form of MermaidJS.
In the examples around the tests, I've omitted the sequenceDiagram part, since that can be added to all strings when parsing these with an annotation processor.
These sequence diagrams can be injected into documentation via an annotation processor to provide a clear overview of all tests and the expected flows from the TCK and CUT. Also for CUT developers having the sequence diagrams inline with the tests will help in debugging issues.

@mkollenstart Just some checkstyle cleanup needed.


To add calculator for calculating Sum of first n terms of a given series 3, 6, 11, …..

Is your feature request related to a problem? Please describe.

A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like

A clear and concise description of what you want to happen.

Hi, I want to work on this issue I will start working on it as soon as I get assigned!! I am a part of GSSoC'21.
Kindly assign this issue to me!
Discord Username : Abhijeet Sinha(P)
Discord Tag: #4018


fix: runs msi-adapter as privileged on openshift

Signed-off-by: Nilekh Chaudhari<EMAIL_ADDRESS>
Reason for Change:

MSI-Adapter container needs to run as privileged when deploying Arc extension on openshift. Similar guidance we follow for provider pods as well.

Requirements

[x] squashed commits
[ ] included documentation
[ ] added unit tests and e2e tests (if applicable).

Issue Fixed:

fixes: https://github.com/Azure/secrets-store-csi-driver-provider-azure/issues/921
Does this change contain code from or inspired by another project?

[ ] Yes
[ ] No

If "Yes," did you notify that project's maintainers and provide attribution?
Special Notes for Reviewers:

Codecov Report

Merging #920 (89bf862) into master (92fa62e) will not change coverage.
The diff coverage is n/a.


doc: re-adds correct suggested usage for pipes

In the current docs, the suggest usage for pipes is the "Flushing a Pipe’s Buffer" example code.
This PR replaces it with the text provided in the v2.7 docs.

@andyross can you please ACK as the assignee for this PR?


feat(clerk-js,shared): getMemberships support for paginated responses + useOrganization adds memberships

Type of change

[ ] 🐛 Bug fix
[ ] 🌟 New feature
[ ] 🔨 Breaking change
[ ] 📖 Refactoring / dependency upgrade / documentation
[ ] other:

Packages affected

[x] @clerk/clerk-js
[ ] @clerk/clerk-react
[ ] @clerk/nextjs
[ ] @clerk/remix
[ ] @clerk/types
[ ] @clerk/themes
[ ] @clerk/localizations
[ ] @clerk/clerk-expo
[ ] @clerk/backend
[ ] @clerk/clerk-sdk-node
[x] @clerk/shared
[ ] @clerk/fastify
[ ] @clerk/chrome-extension
[ ] gatsby-plugin-clerk
[ ] build/tooling/chore

Description

[x] npm test runs as expected.
[x] npm run build runs as expected.
[x] (If applicable) JSDoc comments have been added or updated for any package exports

Does it make sense to add any tests for this change?

@desiprisg there are no test for useOrganization at this moment. I will be adding them in a separate PR as it needs to cover all functionalities of the hook

This PR has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.


Possible CI/CD?

The check seems to be failing? Is it possible to have it run docker-compose with the file in the root and see if that succeeds? Or should we do both compose and build for each container

I think overall it LGTM, but we might wanna consider pushing to a different branch with more updated code or update this branch first? I know the code base on this branch is pretty old.

pulled recent changes. Lmk if it's good to merge

I think overall it LGTM, but we might wanna consider pushing to a different branch with more updated code or update this branch first? I know the code base on this branch is pretty old.

pulled recent changes. Lmk if it's good to merge

the changes are based off of the ui-updates branch

@GenFusion122 Do review, if its good to go we can merge it into main

I'll go merge my unit tests into this branch too, so we can have a collective "cicd" branch. Once that's done and it works fine here then we can merge it into main together.


Go To Definition Very Slow, Often Hangs Indefinitely

Environment data

VS Code version: 1.30.2
Extension version (available under the Extensions sidebar): 2018.12.1
OS and version: Microsoft Windows 10 Pro Version 10.0.17134 Build 17134
Python version: 2.7.11
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): N/A
Relevant/affected Python packages and their versions: N/A

Expected behaviour
Whilst highlighted over a Symbol, Press f12 or right-click and then click "Go To Definition" after at most a second, the code editor jumps to the definition.
Actual behaviour
More often than not,  the process hangs indefinitely, not slowing vscode in any way, but showing the bar representing an async process happening in the background until reload vscode.
Occasionally does go to the definition after a very long wait of up to 2 minutes.
Screen Recording
Steps to reproduce:

Open any Python Script
Use the "Go To Definition" functionality on any symbol call within the script

Logs
Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)
Starting Jedi Python language engine.
##########Linting Output - pylint##########

--------------------------------------------------------------------
Your code has been rated at 10.00/10 (previous run: 10.00/10, +0.00)

Output from Console under the Developer Tools panel (toggle Developer Tools on under Help; turn on source maps to make any tracebacks be useful by running Enable source map support for extension debugging)
XXX

Thanks for letting us know about this, @GeorgeWL.  Are you seing this behavior for simple Python files?  Also, please try with the latest version of the extension and with the language server.  To enable the language server set "python.jediEnabled": false in your settings.json.

Just updated a moment ago and I'm trying those suggestions now.

Simple python files - still broken whilst python.jediEnabled:true
Simple python files - not broken whilst python.jediEnabled:false

Guess that means it's resolved? Then agian, I suppose you need to find the reason why jediEnabled doesn't work in some instances.

One wouldn't be able to use go to definition on print no?
I'll do the next best thing,
def spamTest():
    print('spam')
    pass

spamTest()

Okay...no issue at all for that, with jediEnabled:true and with jediEnabled:false
Does still have the issue for the file which I was seeing the issue in before when I have jediEnabled:true. My only guess is that jedi has trouble with files containing lots of functions?
I don't want to share that file, cause it's from work, so feel it would be breaking some sharing laws.

Sorry for the delay.  Don't worry about not sharing that file. :)
Is there just one file (the one with lots of functions) involved here?  Operations across multiple files can multiply the effect of performance issues in Jedi.

I have the same issue, slightly different OUPUT:
Starting Microsoft Python language server.
##########Linting Output - pylint##########

--------------------------------------------------------------------
Your code has been rated at 10.00/10 (previous run: 10.00/10, +0.00)

Microsoft Python Language Server version <IP_ADDRESS>
Initializing for /usr/local/bin/python

I confirm I see the exact same problem (my Python version being 3.5.2).
Usually reloading the Python extension fixes the problem temporarily; however, after some time the issue still occurs (and one has to re-reload the extension again).  My console output is the below
Starting Microsoft Python language server.
Microsoft Python Language Server version <IP_ADDRESS>
Initializing for /usr/local/bin/python3.6
##########Linting Output - pylint##########

--------------------------------------------------------------------
Your code has been rated at 10.00/10 (previous run: 10.00/10, +0.00)

@yichuan1118, @gennaro-tedesco, note that this issue is about Jedi.  You are both using the language server.

Because we have not heard back with the information we requested, we are closing this issue for now. If you are able to provide the info later on then we will be happy to re-open this issue to pick up where we left off.


fix(cache): fix cache return undef

What this PR does 📖

Fix usercache not returning correct value if not present

I noticed the error appears in console when you send your first message in chat. Is that anything to worry about?

i think that is the code lucas did. not too sure if we still need it or not though


Graphql should add operation name and hash in span

Is your feature request related to a problem? Please describe

Currently the name of the operation and the hash are not provided in the attributes of the span. It just prints query, which is not even the operation name but the operation type. This makes it very difficult to find a given operation in all the traces.
Describe the solution you'd like to see

By default the operation name should be provided as operation.name and the current name should be renamed to type.
Ideally the hash would also be provided. Getting a consistant is however difficult (each server implementation is different), so providing a hook for customization would be best with a sensible default.
Describe alternatives you've considered

I considered using envelop instead and skip the plugin from opentelemetry, but this requires significant changes in the code.
Additional context

Semantic conventions are sets of attributes that standardize how attributes are set for various types of spans. The reason for this is so that if there are multiple instrumented libraries that are tracing the same types of calls (for example you are tracing graphql from 2 different libraries, or even languages), they get the same attributes. This makes it so they can be consistently processed by your tracing backend.
<EMAIL_ADDRESS>It looks like there isn't a semantic convention for graphql, but the database semconv and the rpc semconv might be partially applicable? I think this might be a good case to make an addition to the specification though.

Who would be the one to start the initiative to add GraphQL conventions to the spec?
As GraphQL is gaining popularity it should be a priority to have uniform telemetry data.

@github-actions

@Sytten, is there a particular reason why you think the field should be called operation.name rather than graphql.operation.name, otherwise #847 would seem (to me) to be the right approach? This would hopefully also avoid the need for a naming convention discussion, given that @opentelemetry/instrumentation-graphql already emits a graphql.operation.name field, and fixing it would just be an improvement to what it already does.

I have no opinion on the name of the field per say, just that the current implementation is wrong. Changing it would be a breaking change in any case.

@dyladan can we get this closed?
GraphQL does have standard attributes on requests and responses and that is found in the specification found here:
Request: http://spec.graphql.org/October2021/#sec-Validating-Requests
Response: http://spec.graphql.org/October2021/#sec-Response-Format
So we can get this implemented in the instrumentation.

Not stale

Who would be the one to start the initiative to add GraphQL conventions to the spec?
As GraphQL is gaining popularity it should be a priority to have uniform telemetry data.

@jord1e Sorry for the late response. Anyone can submit a change to the opentelemetry spec. Following the steps in spec/CONTRIBUTING.md#Proposing a change, the first step would be to create an issue. Once the issue is accepted by the spec maintainers, then a PR can be drafted. In this case there is already an open issue and a PR which already has significant reviews.
@jscherer92 I'm sorry I wasn't clear I was referring to the OTel semantic convention specification. It looks like the process is already started with an issue and a PR already opened. The PR also has significant reviews so I expect it will merge soon.

Auto close bots are a bad practice


fix: require now supports variable injection

:tada: This PR is included in version 1.5.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


irmin-pack: use pread/pwrite to avoid lseek calls

Fixes https://github.com/mirage/irmin/issues/1009.
Depends on https://github.com/mirage/index/pull/176.

( the benchmark is here it's an average of 5 runs, for nb of elements = 10000000 and element_size = 1000)

Those are really useful, thanks! Currently adapting them to this PR, and will report back with some results shortly.

Here are the benchmarking results:

metric
value

nb_elements
10,000,000

element size (bytes)
100

repeats
5

(Each run reads/writes nb_elements to the pack, in sequential or random order.)
In short, improvements across the board. Unsurprisingly, random access is more significantly improved.

It's nice to see such a speed-up!


[FEATURE] Manage inbound resolver security group after deployment

Required Basic Info
To properly assess the enhancement request, we require information on the version of the Accelerator you based this request upon:

Accelerator Version:  1.5.1-a

Is your feature request related to a problem? Please describe.
No. Currently the Accelerator creates the inbound resolver security group with no inbound access, but does not provide functionality to manage it going forward. Security group info:
Name: InboundSecurityGroup_sg
Security Group Name: Endpoint_inbound_endpoint_sg
Account deployed: SharedNetwork Account
Description: Security Group for Public Hosted Zone Inbound EndpointRoute53
Describe the solution you'd like
Provide configuration options in the config file to manage the inbound resolver security group similar to other security group options.
Describe alternatives you've considered
The security group can be managed manually at this time.
Additional context
Inbound endpoint: DNS resolvers on your network can forward DNS queries to Route 53 Resolver via this endpoint. The security group restricts the access and the default deployment is no inbound access.

I second this request.   Also. shouldn't the description of the SG be "Security Group for Private Hosted Zone Inbound EndpointRoute53" instead of "Security Group for Public Hosted Zone Inbound EndpointRoute53"

Hey Dan - I've been aware of the problem with the SG description, unfortunately, while it should be a simple fix - it is really hard.  Updating the description is surprisingly a REPLACEMENT action (delete and recreate) in CloudFormation, which also means nothing can be in the security group, and a load of potential cascading issues...  We will get the rules fixed, but no plans to fix the description at this time, unfortunately.


Warning: unnecessary braces around block return value

Describe the bug
The following line produces the warning warning: unnecessary braces around block return value
view! { {format!("See {}", "something"))} }

But without the brackets
view! { format!("See {}", "something")) }

the view macro will take it as a literal and renders format!("See {}", "something") instead of See something
Expected behavior
No such warning, because the brackets are necessary.

Maybe this is not that important. It seems that you should always use the reactive system
view! { "See " {|| "something"} }

over the format macro.
Im still exploring leptos, so Im lacking the knowledge.

The view macro is unnecessary in both those cases. Just return the String.

Maybe this is not that important. It seems that you should always use the reactive system

view! { "See " {|| "something"} }

over the format macro.

No, using a closure here would not be a good idea, unless you're reading something reactive (which is not the case in this example).

 I failed to demonstrate you may want to use e.g. a macro inside view!. For those cases the warning is misleading. Closing for now.


feat: feature flags

Enables feature flags for passing through to libnuke as parameters. Adds corresponding documentation.

:tada: This PR is included in version 1.2.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Orchestration for encryptDataSource

To make the setting for encryptDataSource stored in registry, and refreshed online.

[ ] Add orchestrationEncryptDataSource
[ ] Add yaml configuring method for orchestrationEncryptDataSource
[ ] Add SpringBoot configuring method for orchestrationEncryptDataSource
[ ] Add SpringNameSpace configuring method for orchestrationEncryptDataSource

I will try it


Indian gradient to be added to  the heading

add orange,white and green gradient to the text

#41 the respective colors have been applied to Taste of India in Every Sip


All errors use Exception as a base class, preventing succinct error handling

Problem
Because all of your exceptions inherit directly from the Exception class, it's impossible to write a small exception handler for your library. As it stands, I'm forced to either handle each exception explicitly or catch Exception directly -- both of which are undesirable.
I suggest something like this:

class IPWhoisException(Exception):
    pass

class NetError(IPWhoisException):
    """
    An Exception for when a parameter provided is not an instance of
    ipwhois.net.Net.
    """

class IPDefinedError(IPWhoisException):
    """
    An Exception for when the IP is defined (does not need to be resolved).
    """

# ... etc ...

Which would then allow me to do this:

try:
    # ipwhois lookup
except IPWhoisException:
    # handle it

Thanks

This is fixed in the dev branch. See here:
https://github.com/secynic/ipwhois/issues/205


Add Azure.Storage.Blobs implementation and BlobsTranscriptStore

Fixes #https://github.com/microsoft/botbuilder-dotnet/issues/1686

Thank you for reviewing @gabog !

Ready to merge after checks pass.

Need someone with super powers here.  Checks are passing.  This is ready to merge (has been approved).


Add tests

Please document test dependencies, like in a requirements_test.txt or as extra install requirements.

:+1:


Changes github name for Ellis

Getting married and changing my last name.

/assign jlewi

/lgtm
/approve


Accessibility of read- and write-only markers.

It may not be clear to some people reading the documentation what 🆁 and 🆆 markers mean.
It would be good if they can be replaced by 🆁 and 🆆 so that tool tips will be displayed when they are hovered over.

thats a nice suggestion... will incorporate it soon

+1, saw those markers for the first time and their meaning wasn't obvious. Google brought me here :)


Static generated site not running on my hosting (bluehost)

Hi there
Ran nuxt generate, then uploaded the contents of the dist folder to my hosting and the site does not run. HTML and CSS loads but it looks like Javascript does not run. Runs fine on my local using npm run dev. Runs fine on Netlify. Runs fine on MAMP.
Looking at the console, no errors. Looking in the network tab everything seems to load no 404's
Any help would be greatly appreciated
http://www.mikestott.net/nissan/ #

Can you provide a repo can reproduce your issue ?

I think this one is because of /nissan/ url , you need to provide baseUrl options maybe @unwrittenmike ?

Try this in your nuxt.config.js
router: {
    base: '/nissan/'
  }

@clarkdo  Will provide soonest. I can reproduce. I used one of the nuxt example repo's and added an alert on a button click. That still isn't working. I tried to rule out any bugs in my code being the issue. If I put breakpoints in the javascript that is loading the code execution pauses. It's almost if it's jut not running the app code...

@piyushchauhan2011  my original config was:
router: {     base: 'http://www.mikestott.net/nissan/'   },
changed it to:
router: {     base: '/nissan/'   },
as @nicoladl suggested

@clarkdo , @piyushchauhan2011 , @nicoladl  Code here has been updated to use this config:
http://mikestott.net/nissan/
router: {     base: '/nissan/'   },
Still not getting my alert to fire off when clicking the button which says test.
Very strange issue. Thanks for the help by way and thanks for taking a look :)

@unwrittenmike can you provide a repo with this example?
thank you

@nicoladl @clarkdo My repo: git@bitbucket.org:unwrittenmike/nuxtalerttest.git Thanks

@unwrittenmike change the event handler.
From:
@click="clickMe"
To:
v-on:click="clickMe"
Let me know if it works for you

v-on and @click are the same theoretically.
However I noticed with some elements you might need @click.native to make it "click"
@unwrittenmike have you tried that?

@bovas85  I haven't tried that although my console.log() isn't running in mounted() either so I suspect that the issue is not with the click handler

@unwrittenmike cloning your repo and changed the event handler works for me

@nicoladl  Running it locally with npm run dev works for me, running it locally using  mamp works for me... it's when I use npm run generate and upload to my hosting(bluehost) is where it wont run...

Magically started working on my hosting!


D2Solo doesn't handle Windows UI scaling properly

When launching D2Solo with UI scale already set to 200%, the window doesn't appear anywhere on the screen. If I go back to 100% and launch it, it appears in the top right corner just fine. If I change UI scale from 100% to 200% while it's already running, it also resizes and stays in the top right corner.

If there was a hotkey to switch modes, in addition to the hide/show window hotkey, this wouldn't be as much of an issue. Perhaps Ctrl+Shift+F10 could be added to swap modes?


Update dependency pytest to v7

This PR contains the following updates:

Package
Type
Update
Change

pytest (source, changelog)
dev-dependencies
major
^6.2.2 -> ^7.0.0

Release Notes

pytest-dev/pytest
v7.1.1
Compare Source
pytest 7.1.1 (2022-03-17)
Bug Fixes

#9767: Fixed a regression in pytest 7.1.0 where some conftest.py files outside of the source tree (e.g. in the [site-packages]{.title-ref} directory) were not picked up.

v7.1.0
Compare Source
pytest 7.1.0 (2022-03-13)
Breaking Changes

#8838: As per our policy, the following features have been deprecated in the 6.X series and are now
removed:

pytest._fillfuncargs function.
pytest_warning_captured hook - use pytest_warning_recorded instead.
-k -foobar syntax - use -k 'not foobar' instead.
-k foobar: syntax.
pytest.collect module - import from pytest directly.

For more information consult
Deprecations and Removals in the docs.

#9437: Dropped support for Python 3.6, which reached end-of-life at 2021-12-23.

Improvements

#5192: Fixed test output for some data types where -v would show less information.
Also, when showing diffs for sequences, -q would produce full diffs instead of the expected diff.

#9362: pytest now avoids specialized assert formatting when it is detected that the default __eq__ is overridden in attrs or dataclasses.

#9536: When -vv is given on command line, show skipping and xfail reasons in full instead of truncating them to fit the terminal width.

#9644: More information about the location of resources that led Python to raise ResourceWarning{.interpreted-text role="class"} can now
be obtained by enabling tracemalloc{.interpreted-text role="mod"}.
See resource-warnings{.interpreted-text role="ref"} for more information.

#9678: More types are now accepted in the ids argument to @pytest.mark.parametrize.
Previously only [str]{.title-ref}, [float]{.title-ref}, [int]{.title-ref} and [bool]{.title-ref} were accepted;
now [bytes]{.title-ref}, [complex]{.title-ref}, [re.Pattern]{.title-ref}, [Enum]{.title-ref} and anything with a [__name__]{.title-ref} are also accepted.

#9692: pytest.approx{.interpreted-text role="func"} now raises a TypeError{.interpreted-text role="class"} when given an unordered sequence (such as set{.interpreted-text role="class"}).
Note that this implies that custom classes which only implement __iter__ and __len__ are no longer supported as they don't guarantee order.

Bug Fixes

#8242: The deprecation of raising unittest.SkipTest{.interpreted-text role="class"} to skip collection of
tests during the pytest collection phase is reverted - this is now a supported
feature again.

#9493: Symbolic link components are no longer resolved in conftest paths.
This means that if a conftest appears twice in collection tree, using symlinks, it will be executed twice.
For example, given

tests/real/conftest.py
tests/real/test_it.py
tests/link -> tests/real

running pytest tests now imports the conftest twice, once as tests/real/conftest.py and once as tests/link/conftest.py.
This is a fix to match a similar change made to test collection itself in pytest 6.0 (see 6523{.interpreted-text role="pull"} for details).

#9626: Fixed count of selected tests on terminal collection summary when there were errors or skipped modules.
If there were errors or skipped modules on collection, pytest would mistakenly subtract those from the selected count.

#9645: Fixed regression where --import-mode=importlib used together with PYTHONPATH{.interpreted-text role="envvar"} or pythonpath{.interpreted-text role="confval"} would cause import errors in test suites.

#9708: pytester{.interpreted-text role="fixture"} now requests a monkeypatch{.interpreted-text role="fixture"} fixture instead of creating one internally. This solves some issues with tests that involve pytest environment variables.

#9730: Malformed pyproject.toml files now produce a clearer error message.

v7.0.1
Compare Source
pytest 7.0.1 (2022-02-11)
Bug Fixes

#9608: Fix invalid importing of importlib.readers in Python 3.9.
#9610: Restore [UnitTestFunction.obj]{.title-ref} to return unbound rather than bound method.
Fixes a crash during a failed teardown in unittest TestCases with non-default [__init__]{.title-ref}.
Regressed in pytest 7.0.0.
#9636: The pythonpath plugin was renamed to python_path. This avoids a conflict with the pytest-pythonpath plugin.
#9642: Fix running tests by id with :: in the parametrize portion.
#9643: Delay issuing a ~pytest.PytestWarning{.interpreted-text role="class"} about diamond inheritance involving ~pytest.Item{.interpreted-text role="class"} and
~pytest.Collector{.interpreted-text role="class"} so it can be filtered using standard warning filters <warnings>{.interpreted-text role="ref"}.

v7.0.0
Compare Source
pytest 7.0.0 (2022-02-03)
(Please see the full set of changes for this release also in the 7.0.0rc1 notes below)
Deprecations

#9488: If custom subclasses of nodes like pytest.Item{.interpreted-text role="class"} override the
__init__ method, they should take **kwargs. See
uncooperative-constructors-deprecated{.interpreted-text role="ref"} for details.
Note that a deprection warning is only emitted when there is a conflict in the
arguments pytest expected to pass. This deprecation was already part of pytest
7.0.0rc1 but wasn't documented.

Bug Fixes

#9355: Fixed error message prints function decorators when using assert in Python 3.8 and above.
#9396: Ensure pytest.Config.inifile{.interpreted-text role="attr"} is available during the pytest_cmdline_main <_pytest.hookspec.pytest_cmdline_main>{.interpreted-text role="func"} hook (regression during 7.0.0rc1).

Improved Documentation

#9404: Added extra documentation on alternatives to common misuses of [pytest.warns(None)]{.title-ref} ahead of its deprecation.
#9505: Clarify where the configuration files are located. To avoid confusions documentation mentions
that configuration file is located in the root of the repository.

Trivial/Internal Changes

#9521: Add test coverage to assertion rewrite path.

pytest 7.0.0rc1 (2021-12-06)
Breaking Changes

#7259: The Node.reportinfo() <non-python tests>{.interpreted-text role="ref"} function first return value type has been expanded from [py.path.local | str]{.title-ref} to [os.PathLike[str] | str]{.title-ref}.
Most plugins which refer to [reportinfo()]{.title-ref} only define it as part of a custom pytest.Item{.interpreted-text role="class"} implementation.
Since [py.path.local]{.title-ref} is a [os.PathLike[str]]{.title-ref}, these plugins are unaffacted.
Plugins and users which call [reportinfo()]{.title-ref}, use the first return value and interact with it as a [py.path.local]{.title-ref}, would need to adjust by calling [py.path.local(fspath)]{.title-ref}.
Although preferably, avoid the legacy [py.path.local]{.title-ref} and use [pathlib.Path]{.title-ref}, or use [item.location]{.title-ref} or [item.path]{.title-ref}, instead.
Note: pytest was not able to provide a deprecation period for this change.

#8246: --version now writes version information to stdout rather than stderr.

#8733: Drop a workaround for pyreadline that made it work with --pdb.
The workaround was introduced in #1281 in 2015, however since then
pyreadline seems to have gone unmaintained, is generating
warnings, and will stop working on Python 3.10.

#9061: Using pytest.approx{.interpreted-text role="func"} in a boolean context now raises an error hinting at the proper usage.
It is apparently common for users to mistakenly use pytest.approx like this:
assert pytest.approx(actual, expected)

While the correct usage is:
assert actual == pytest.approx(expected)

The new error message helps catch those mistakes.

#9277: The pytest.Instance collector type has been removed.
Importing pytest.Instance or _pytest.python.Instance returns a dummy type and emits a deprecation warning.
See instance-collector-deprecation{.interpreted-text role="ref"} for details.

#9308: PytestRemovedIn7Warning deprecation warnings are now errors by default.
Following our plan to remove deprecated features with as little disruption as
possible, all warnings of type PytestRemovedIn7Warning now generate errors
instead of warning messages by default.
The affected features will be effectively removed in pytest 7.1, so please consult the
deprecations{.interpreted-text role="ref"} section in the docs for directions on how to update existing code.
In the pytest 7.0.X series, it is possible to change the errors back into warnings as a
stopgap measure by adding this to your pytest.ini file:
[pytest]
filterwarnings =
    ignore::pytest.PytestRemovedIn7Warning

But this will stop working when pytest 7.1 is released.
If you have concerns about the removal of a specific feature, please add a
comment to 9308{.interpreted-text role="issue"}.

Deprecations

#7259: py.path.local arguments for hooks have been deprecated. See the deprecation note <legacy-path-hooks-deprecated>{.interpreted-text role="ref"} for full details.
py.path.local arguments to Node constructors have been deprecated. See the deprecation note <node-ctor-fspath-deprecation>{.interpreted-text role="ref"} for full details.
::: {.note}
::: {.admonition-title}
Note
:::
The name of the ~_pytest.nodes.Node{.interpreted-text role="class"} arguments and attributes (the
new attribute being path) is the opposite of the situation for hooks
(the old argument being path).
This is an unfortunate artifact due to historical reasons, which should be
resolved in future versions as we slowly get rid of the py{.interpreted-text role="pypi"}
dependency (see 9283{.interpreted-text role="issue"} for a longer discussion).
:::

#7469: Directly constructing the following classes is now deprecated:

_pytest.mark.structures.Mark
_pytest.mark.structures.MarkDecorator
_pytest.mark.structures.MarkGenerator
_pytest.python.Metafunc
_pytest.runner.CallInfo
_pytest._code.ExceptionInfo
_pytest.config.argparsing.Parser
_pytest.config.argparsing.OptionGroup
_pytest.pytester.HookRecorder

These constructors have always been considered private, but now issue a deprecation warning, which may become a hard error in pytest 8.

#8242: Raising unittest.SkipTest{.interpreted-text role="class"} to skip collection of tests during the
pytest collection phase is deprecated. Use pytest.skip{.interpreted-text role="func"} instead.
Note: This deprecation only relates to using unittest.SkipTest{.interpreted-text role="class"} during test
collection. You are probably not doing that. Ordinary usage of
unittest.SkipTest{.interpreted-text role="class"} / unittest.TestCase.skipTest{.interpreted-text role="meth"} /
unittest.skip{.interpreted-text role="func"} in unittest test cases is fully supported.

#8315: Several behaviors of Parser.addoption <pytest.Parser.addoption>{.interpreted-text role="meth"} are now
scheduled for removal in pytest 8 (deprecated since pytest 2.4.0):

parser.addoption(..., help=".. %default ..") - use %(default)s instead.
parser.addoption(..., type="int/string/float/complex") - use type=int etc. instead.

#8447: Defining a custom pytest node type which is both an pytest.Item <Item>{.interpreted-text role="class"} and a pytest.Collector <Collector>{.interpreted-text role="class"} (e.g. pytest.File <File>{.interpreted-text role="class"}) now issues a warning.
It was never sanely supported and triggers hard to debug errors.
See the deprecation note <diamond-inheritance-deprecated>{.interpreted-text role="ref"} for full details.

#8592: pytest_cmdline_preparse{.interpreted-text role="hook"} has been officially deprecated. It will be removed in a future release. Use pytest_load_initial_conftests{.interpreted-text role="hook"} instead.
See the deprecation note <cmdline-preparse-deprecated>{.interpreted-text role="ref"} for full details.

#8645: pytest.warns(None) <pytest.warns>{.interpreted-text role="func"} is now deprecated because many people used
it to mean "this code does not emit warnings", but it actually had the effect of
checking that the code emits at least one warning of any type - like pytest.warns()
or pytest.warns(Warning).

#8948: pytest.skip(msg=...) <pytest.skip>{.interpreted-text role="func"}, pytest.fail(msg=...) <pytest.fail>{.interpreted-text role="func"} and pytest.exit(msg=...) <pytest.exit>{.interpreted-text role="func"}
signatures now accept a reason argument instead of msg. Using msg still works, but is deprecated and will be removed in a future release.
This was changed for consistency with pytest.mark.skip <pytest.mark.skip>{.interpreted-text role="func"} and pytest.mark.xfail <pytest.mark.xfail>{.interpreted-text role="func"} which both accept
reason as an argument.

#8174: The following changes have been made to types reachable through pytest.ExceptionInfo.traceback{.interpreted-text role="attr"}:

The path property of _pytest.code.Code returns Path instead of py.path.local.
The path property of _pytest.code.TracebackEntry returns Path instead of py.path.local.

There was no deprecation period for this change (sorry!).

Features

#5196: Tests are now ordered by definition order in more cases.
In a class hierarchy, tests from base classes are now consistently ordered before tests defined on their subclasses (reverse MRO order).

#7132: Added two environment variables PYTEST_THEME{.interpreted-text role="envvar"} and PYTEST_THEME_MODE{.interpreted-text role="envvar"} to let the users customize the pygments theme used.

#7259: Added cache.mkdir() <pytest.Cache.mkdir>{.interpreted-text role="meth"}, which is similar to the existing cache.makedir() <pytest.Cache.makedir>{.interpreted-text role="meth"},
but returns a pathlib.Path{.interpreted-text role="class"} instead of a legacy py.path.local.
Added a paths type to parser.addini() <pytest.Parser.addini>{.interpreted-text role="meth"},
as in parser.addini("mypaths", "my paths", type="paths"),
which is similar to the existing pathlist,
but returns a list of pathlib.Path{.interpreted-text role="class"} instead of legacy py.path.local.

#7469: The types of objects used in pytest's API are now exported so they may be used in type annotations.
The newly-exported types are:

pytest.Config for Config <pytest.Config>{.interpreted-text role="class"}.
pytest.Mark for marks <pytest.Mark>{.interpreted-text role="class"}.
pytest.MarkDecorator for mark decorators <pytest.MarkDecorator>{.interpreted-text role="class"}.
pytest.MarkGenerator for the pytest.mark <pytest.MarkGenerator>{.interpreted-text role="class"} singleton.
pytest.Metafunc for the metafunc <pytest.MarkGenerator>{.interpreted-text role="class"} argument to the pytest_generate_tests{.interpreted-text role="hook"} hook.
pytest.CallInfo for the CallInfo <pytest.CallInfo>{.interpreted-text role="class"} type passed to various hooks.
pytest.PytestPluginManager for PytestPluginManager <pytest.PytestPluginManager>{.interpreted-text role="class"}.
pytest.ExceptionInfo for the ExceptionInfo <pytest.ExceptionInfo>{.interpreted-text role="class"} type returned from pytest.raises{.interpreted-text role="func"} and passed to various hooks.
pytest.Parser for the Parser <pytest.Parser>{.interpreted-text role="class"} type passed to the pytest_addoption{.interpreted-text role="hook"} hook.
pytest.OptionGroup for the OptionGroup <pytest.OptionGroup>{.interpreted-text role="class"} type returned from the parser.addgroup <pytest.Parser.getgroup>{.interpreted-text role="func"} method.
pytest.HookRecorder for the HookRecorder <pytest.HookRecorder>{.interpreted-text role="class"} type returned from ~pytest.Pytester{.interpreted-text role="class"}.
pytest.RecordedHookCall for the RecordedHookCall <pytest.HookRecorder>{.interpreted-text role="class"} type returned from ~pytest.HookRecorder{.interpreted-text role="class"}.
pytest.RunResult for the RunResult <pytest.RunResult>{.interpreted-text role="class"} type returned from ~pytest.Pytester{.interpreted-text role="class"}.
pytest.LineMatcher for the LineMatcher <pytest.RunResult>{.interpreted-text role="class"} type used in ~pytest.RunResult{.interpreted-text role="class"} and others.
pytest.TestReport for the TestReport <pytest.TestReport>{.interpreted-text role="class"} type used in various hooks.
pytest.CollectReport for the CollectReport <pytest.CollectReport>{.interpreted-text role="class"} type used in various hooks.

Constructing most of them directly is not supported; they are only meant for use in type annotations.
Doing so will emit a deprecation warning, and may become a hard-error in pytest 8.0.
Subclassing them is also not supported. This is not currently enforced at runtime, but is detected by type-checkers such as mypy.

#7856: --import-mode=importlib <import-modes>{.interpreted-text role="ref"} now works with features that
depend on modules being on :pysys.modules{.interpreted-text role="data"}, such as pickle{.interpreted-text role="mod"} and dataclasses{.interpreted-text role="mod"}.

#8144: The following hooks now receive an additional pathlib.Path argument, equivalent to an existing py.path.local argument:

pytest_ignore_collect{.interpreted-text role="hook"} - The collection_path parameter (equivalent to existing path parameter).
pytest_collect_file{.interpreted-text role="hook"} - The file_path parameter (equivalent to existing path parameter).
pytest_pycollect_makemodule{.interpreted-text role="hook"} - The module_path parameter (equivalent to existing path parameter).
pytest_report_header{.interpreted-text role="hook"} - The start_path parameter (equivalent to existing startdir parameter).
pytest_report_collectionfinish{.interpreted-text role="hook"} - The start_path parameter (equivalent to existing startdir parameter).

::: {.note}
::: {.admonition-title}
Note
:::
The name of the ~_pytest.nodes.Node{.interpreted-text role="class"} arguments and attributes (the
new attribute being path) is the opposite of the situation for hooks
(the old argument being path).
This is an unfortunate artifact due to historical reasons, which should be
resolved in future versions as we slowly get rid of the py{.interpreted-text role="pypi"}
dependency (see 9283{.interpreted-text role="issue"} for a longer discussion).
:::

#8251: Implement Node.path as a pathlib.Path. Both the old fspath and this new attribute gets set no matter whether path or fspath (deprecated) is passed to the constructor. It is a replacement for the fspath attribute (which represents the same path as py.path.local). While fspath is not deprecated yet
due to the ongoing migration of methods like ~_pytest.Item.reportinfo{.interpreted-text role="meth"}, we expect to deprecate it in a future release.
::: {.note}
::: {.admonition-title}
Note
:::
The name of the ~_pytest.nodes.Node{.interpreted-text role="class"} arguments and attributes (the
new attribute being path) is the opposite of the situation for hooks
(the old argument being path).
This is an unfortunate artifact due to historical reasons, which should be
resolved in future versions as we slowly get rid of the py{.interpreted-text role="pypi"}
dependency (see 9283{.interpreted-text role="issue"} for a longer discussion).
:::

#8421: pytest.approx{.interpreted-text role="func"} now works on ~decimal.Decimal{.interpreted-text role="class"} within mappings/dicts and sequences/lists.

#8606: pytest invocations with --fixtures-per-test and --fixtures have been enriched with:

Fixture location path printed with the fixture name.
First section of the fixture's docstring printed under the fixture name.
Whole of fixture's docstring printed under the fixture name using --verbose option.

#8761: New version-tuple{.interpreted-text role="ref"} attribute, which makes it simpler for users to do something depending on the pytest version (such as declaring hooks which are introduced in later versions).

#8789: Switch TOML parser from toml to tomli for TOML v1.0.0 support in pyproject.toml.

#8920: Added pytest.Stash{.interpreted-text role="class"}, a facility for plugins to store their data on ~pytest.Config{.interpreted-text role="class"} and ~_pytest.nodes.Node{.interpreted-text role="class"}s in a type-safe and conflict-free manner.
See plugin-stash{.interpreted-text role="ref"} for details.

#8953: RunResult <_pytest.pytester.RunResult>{.interpreted-text role="class"} method assert_outcomes <_pytest.pytester.RunResult.assert_outcomes>{.interpreted-text role="meth"} now accepts a
warnings argument to assert the total number of warnings captured.

#8954: --debug flag now accepts a str{.interpreted-text role="class"} file to route debug logs into, remains defaulted to [pytestdebug.log]{.title-ref}.

#9023: Full diffs are now always shown for equality assertions of iterables when
[CI]{.title-ref} or BUILD_NUMBER is found in the environment, even when -v isn't
used.

#9113: RunResult <_pytest.pytester.RunResult>{.interpreted-text role="class"} method assert_outcomes <_pytest.pytester.RunResult.assert_outcomes>{.interpreted-text role="meth"} now accepts a
deselected argument to assert the total number of deselected tests.

#9114: Added pythonpath{.interpreted-text role="confval"} setting that adds listed paths to sys.path{.interpreted-text role="data"} for the duration of the test session. If you currently use the pytest-pythonpath or pytest-srcpaths plugins, you should be able to replace them with built-in [pythonpath]{.title-ref} setting.

Improvements

#7480: A deprecation scheduled to be removed in a major version X (e.g. pytest 7, 8, 9, ...) now uses warning category [PytestRemovedInXWarning]{.title-ref},
a subclass of ~pytest.PytestDeprecationWarning{.interpreted-text role="class"},
instead of PytestDeprecationWarning{.interpreted-text role="class"} directly.
See backwards-compatibility{.interpreted-text role="ref"} for more details.

#7864: Improved error messages when parsing warning filters.
Previously pytest would show an internal traceback, which besides being ugly sometimes would hide the cause
of the problem (for example an ImportError while importing a specific warning type).

#8335: Improved pytest.approx{.interpreted-text role="func"} assertion messages for sequences of numbers.
The assertion messages now dumps a table with the index and the error of each diff.
Example:
>       assert [1, 2, 3, 4] == pytest.approx([1, 3, 3, 5])
E       assert comparison failed for 2 values:
E         Index | Obtained | Expected
E         1     | 2        | 3 +- 3.0e-06
E         3     | 4        | 5 +- 5.0e-06

#8403: By default, pytest will truncate long strings in assert errors so they don't clutter the output too much,
currently at 240 characters by default.
However, in some cases the longer output helps, or is even crucial, to diagnose a failure. Using -v will
now increase the truncation threshold to 2400 characters, and -vv or higher will disable truncation entirely.

#8509: Fixed issue where unittest.TestCase.setUpClass{.interpreted-text role="meth"} is not called when a test has [/]{.title-ref} in its name since pytest 6.2.0.
This refers to the path part in pytest node IDs, e.g. TestClass::test_it in the node ID tests/test_file.py::TestClass::test_it.
Now, instead of assuming that the test name does not contain /, it is assumed that test path does not contain ::. We plan to hopefully make both of these work in the future.

#8803: It is now possible to add colors to custom log levels on cli log.
By using add_color_level <_pytest.logging.add_color_level>{.interpreted-text role="func"} from a pytest_configure hook, colors can be added:
logging_plugin = config.pluginmanager.get_plugin('logging-plugin')
logging_plugin.log_cli_handler.formatter.add_color_level(logging.INFO, 'cyan')
logging_plugin.log_cli_handler.formatter.add_color_level(logging.SPAM, 'blue')

See log_colors{.interpreted-text role="ref"} for more information.

#8822: When showing fixture paths in [--fixtures]{.title-ref} or [--fixtures-by-test]{.title-ref}, fixtures coming from pytest itself now display an elided path, rather than the full path to the file in the [site-packages]{.title-ref} directory.

#8898: Complex numbers are now treated like floats and integers when generating parameterization IDs.

#9062: --stepwise-skip now implicitly enables --stepwise and can be used on its own.

#9205: pytest.Cache.set{.interpreted-text role="meth"} now preserves key order when saving dicts.

Bug Fixes

#7124: Fixed an issue where __main__.py would raise an ImportError when --doctest-modules was provided.

#8061: Fixed failing staticmethod test cases if they are inherited from a parent test class.

#8192: testdir.makefile now silently accepts values which don't start with . to maintain backward compatibility with older pytest versions.
pytester.makefile now issues a clearer error if the . is missing in the ext argument.

#8258: Fixed issue where pytest's faulthandler support would not dump traceback on crashes
if the faulthandler{.interpreted-text role="mod"} module was already enabled during pytest startup (using
python -X dev -m pytest for example).

#8317: Fixed an issue where illegal directory characters derived from getpass.getuser() raised an OSError.

#8367: Fix Class.from_parent so it forwards extra keyword arguments to the constructor.

#8377: The test selection options pytest -k and pytest -m now support matching
names containing forward slash (/) characters.

#8384: The @pytest.mark.skip decorator now correctly handles its arguments. When the reason argument is accidentally given both positional and as a keyword (e.g. because it was confused with skipif), a TypeError now occurs. Before, such tests were silently skipped, and the positional argument ignored. Additionally, reason is now documented correctly as positional or keyword (rather than keyword-only).

#8394: Use private names for internal fixtures that handle classic setup/teardown so that they don't show up with the default --fixtures invocation (but they still show up with --fixtures -v).

#8456: The required_plugins{.interpreted-text role="confval"} config option now works correctly when pre-releases of plugins are installed, rather than falsely claiming that those plugins aren't installed at all.

#8464: -c <config file> now also properly defines rootdir as the directory that contains <config file>.

#8503: pytest.MonkeyPatch.syspath_prepend{.interpreted-text role="meth"} no longer fails when
setuptools is not installed.
It now only calls pkg_resources.fixup_namespace_packages{.interpreted-text role="func"} if
pkg_resources was previously imported, because it is not needed otherwise.

#8548: Introduce fix to handle precision width in log-cli-format in turn to fix output coloring for certain formats.

#8796: Fixed internal error when skipping doctests.

#8983: The test selection options pytest -k and pytest -m now support matching names containing backslash ([\]{.title-ref}) characters.
Backslashes are treated literally, not as escape characters (the values being matched against are already escaped).

#8990: Fix [pytest -vv]{.title-ref} crashing with an internal exception [AttributeError: 'str' object has no attribute 'relative_to']{.title-ref} in some cases.

#9077: Fixed confusing error message when request.fspath / request.path was accessed from a session-scoped fixture.

#9131: Fixed the URL used by --pastebin to use bpa.st.

#9163: The end line number and end column offset are now properly set for rewritten assert statements.

#9169: Support for the files API from importlib.resources within rewritten files.

#9272: The nose compatibility module-level fixtures [setup()]{.title-ref} and [teardown()]{.title-ref} are now only called once per module, instead of for each test function.
They are now called even if object-level [setup]{.title-ref}/[teardown]{.title-ref} is defined.

Improved Documentation

#4320: Improved docs for [pytester.copy_example]{.title-ref}.
#5105: Add automatically generated plugin-list{.interpreted-text role="ref"}. The list is updated on a periodic schedule.
#8337: Recommend numpy.testing module on pytest.approx{.interpreted-text role="func"} documentation.
#8655: Help text for --pdbcls more accurately reflects the option's behavior.
#9210: Remove incorrect docs about confcutdir being a configuration option: it can only be set through the --confcutdir command-line option.
#9242: Upgrade readthedocs configuration to use a newer Ubuntu version` with better unicode support for PDF docs.
#9341: Various methods commonly used for non-python tests{.interpreted-text role="ref"} are now correctly documented in the reference docs. They were undocumented previously.

Trivial/Internal Changes

#8133: Migrate to setuptools_scm 6.x to use SETUPTOOLS_SCM_PRETEND_VERSION_FOR_PYTEST for more robust release tooling.
#8174: The following changes have been made to internal pytest types/functions:

The _pytest.code.getfslineno() function returns Path instead of py.path.local.
The _pytest.python.path_matches_patterns() function takes Path instead of py.path.local.
The _pytest._code.Traceback.cut() function accepts any os.PathLike[str], not just py.path.local.

#8248: Internal Restructure: let python.PyObjMixin inherit from nodes.Node to carry over typing information.
#8432: Improve error message when pytest.skip{.interpreted-text role="func"} is used at module level without passing [allow_module_level=True]{.title-ref}.
#8818: Ensure regendoc opts out of TOX_ENV cachedir selection to ensure independent example test runs.
#8913: The private CallSpec2._arg2scopenum attribute has been removed after an internal refactoring.
#8967: pytest_assertion_pass{.interpreted-text role="hook"} is no longer considered experimental and
future changes to it will be considered more carefully.
#9202: Add github action to upload coverage report to codecov instead of bash uploader.
#9225: Changed the command used to create sdist and wheel artifacts: using the build package instead of setup.py.
#9351: Correct minor typos in doc/en/example/special.rst.

v6.2.5
Compare Source
pytest 6.2.5 (2021-08-29)
Trivial/Internal Changes

#8494: Python 3.10 is now supported.
#9040: Enable compatibility with pluggy 1.0 or later.

Configuration
📅 Schedule: At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by Renovate Bot.

Autoclosing Skipped
This PR has been flagged for autoclosing, however it is being skipped due to the branch being already modified. Please close/delete it manually or report a bug if you think this is in error.


docker run command fixed. correct docker image and network

Signed-off-by: Jonas Schubert<EMAIL_ADDRESS>Description

used docker image used in the docker run command did not match the previously downloaded one
network log-ingestion_opensearch_net was not created, so I corrected it to the one which was created at my system

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Hi @jnschbrt. Thanks for your interest in Data Prepper and for finding this issue. docker-compose prepends the folder name that it is run in to the network that is defined. Just to confirm, you ran the docker-compose.yaml from the folder data-prepper-example?
This guide wrongly assumes that everyone will run the docker-compose.yaml from the ../data-prepper/examples/log-ingestion folder, and should be updated to clarify that the network name is prepended with the location it is run from. Another alternative would be to look into ways that this prepend can be disabled on Docker's end. I have created an issue for this fix to be made ()