[DDW-427] Issues on redeem rewards screen

This PR fixes issues on redeem rewards screen. Removes double error messages and fixes validation on button. Also fixes closing of Daedalus app while not showing wrong screen after close button click.
Screenshots

Translations
JP - https://docs.google.com/document/d/1qHNA_o8ROIqV4nZ7IDrxViKw_T9oehWyBYc1EY6mkZQ/edit
Testing Checklist

Slack QA thread

Testing Summary
Issue summary for 15096:
New
1 - Two different minimum required ada for the same wallet displayed. The first time I selected a wallet with 0 ADA, the error message displayed that the minimum ada needed to be 1 ADA, but then, when I chose a wallet with 1 ADA, the minimum ada required changed to 1.174301 ADA (which was OK for this wallet). However, when I chose the wallet with 0 ADA again, the minimum required ada displayed at 1.174301 ADA. I believe error message requiring minimum of 1 ADA was wrong. See here
2 - When the ada that I had in a wallet was 1.174301, the error message displayed it required minimum ada of 1.174301.  I expected this not to display an error. See here
3 - I selected wallet with 0 ADA, the min required ada was displayed at 1.174301 ADA, then I selected another wallet. When I reselected the wallet with 0 ADA, the min ada required was now displayed at 2 ADA. See screenshot1 and screenshot2
Fixed:
1 - When selecting a syncing wallet, the wrong message is displayed. Here is a screenshot.
2 - When the existing wallet has 1 ADA, upon clicking "Continue", error message displayed as "intl.formatMessage(error)" and console errors seem to point to "not enough ada for fees". I expected this transaction to go through but it didn't. Please see here
3 - I think the value in which this message is displayed should be modified. We may need some clarification, but If I remember correctly, the wallet should have >= 1 ADA to cover the fees. Also if the message is displayed, the user should not be able to move to the next screen
4 - Regarding the second validation message: When the wallet has less than 10 ADA the validation message is displayed, but the user can proceed with the redemption (See recording here).
5 - When accessing the "Redeem rewards" screen while Daedalus is syncing, a blank screen is displayed, instead of the corresponding message. Here is a recording.
6 - The first validation message is still visible. Here is a screenshot. That was meant to be removed, the second validation is the one that should stay.
7 - The "Syncing wallets" screen is not visible anymore when Daedalus is closed. Instead I observed a blank screen. I expected to see the "Stopping node/closing Daedalus" screen. Please see animated gif here
8 - When the wallet is selected while syncing, no message is displayed. Here is a screenshot.
9 - As a continuation of the previous issue, when another wallet is selected, the message is not cleared. Here is a recording.
Not relevant anymore
1 - When the wallet has 1 ADA, the message of "insufficient ada" is displayed (after submission). The minimum was supposed to be 1 ADA. Here is a screenshot.
Review Checklist
Basics

[ ] PR has been assigned and has appropriate labels (feature/bug/chore, release-x.x.x)
[ ] PR is updated to the most recent version of the target branch (and there are no conflicts)
[ ] PR has a good description that summarizes all changes
[ ] PR has default-sized Daedalus window screenshots or animated GIFs of important UI changes:

[ ] In English
[ ] In Japanese

[ ] CHANGELOG entry has been added to the top of the appropriate section (Features, Fixes, Chores) and is linked to the correct PR on GitHub
[ ] Automated tests: All acceptance and unit tests are passing (yarn test)
[ ] Manual tests (minimum tests should cover newly added feature/fix): App works correctly in development build (yarn dev)
[ ] Manual tests (minimum tests should cover newly added feature/fix): App works correctly in production build (yarn package / CI builds)
[ ] There are no flow errors or warnings (yarn flow:test)
[ ] There are no lint errors or warnings (yarn lint)
[ ] There are no prettier errors or warnings (yarn prettier:check)
[ ] There are no missing translations (running yarn manage:translations produces no changes)
[ ] Text changes are proofread and approved (Jane Wild / Amy Reeve)
[ ] Japanese text changes are proofread and approved (Junko Oda)
[ ] UI changes look good in all themes (Alexander Rukin)
[ ] Storybook works and no stories are broken (yarn storybook)
[ ] In case of dependency changes yarn.lock file is updated

Code Quality

[ ] Important parts of the code are properly commented and documented
[ ] Code is properly typed with flow
[ ] React components are split-up enough to avoid unnecessary re-renderings
[ ] Any code that only works in main process is neatly separated from components

Testing

[ ] New feature/change is covered by acceptance tests
[ ] New feature/change is manually tested and approved by QA team
[ ] All existing acceptance tests are still up-to-date
[ ] New feature/change is covered by Daedalus Testing scenario
[ ] All existing Daedalus Testing scenarios are still up-to-date

After Review

[ ] Merge the PR
[ ] Delete the source branch
[ ] Move the ticket to done column on the YouTrack board
[ ] Update Slack QA thread by marking it with a green checkmark

Hi @DeeJayElly
Here are my findings for build 15003.
As elaborated in Jira ticket DDW-427
Issue 1 Fixed
Working as expected when wallet has between 0 and 10 ADA. See here
Working as expected when wallet has 0 ADA. See here
Issue 2 Pending
The "Syncing wallets" screen is not visible anymore when Daedalus is closed. Instead I observed a blank screen. Please see animated gif here

@DeeJayElly why is "ada" in this context replaced with "ADA"? This is not correct. It should in "ADA" form ONLY when it is following a number - e.g. 100 ADA...

@nikolaglumac I reported this, my bad. I'll remove it from the card.
@DeeJayElly here is an issue on this PR:

When accessing the "Redeem rewards" screen while Daedalus is syncing, a blank screen is displayed, instead of the corresponding message. Here is a recording.

This PR fixes issues on redeem rewards screen. Removes double error messages and fixes validation on button. Also fixes closing of Daedalus app while not showing wrong screen after close button click.
Screenshots

Screenshot

Testing Checklist

Slack QA thread

Review Checklist
Basics

[ ]  PR has been assigned and has appropriate labels (feature/bug/chore, release-x.x.x)

[ ]  PR is updated to the most recent version of the target branch (and there are no conflicts)

[ ]  PR has a good description that summarizes all changes

[ ]  PR has default-sized Daedalus window screenshots or animated GIFs of important UI changes:

[ ]  In English
[ ]  In Japanese

[ ]  CHANGELOG entry has been added to the top of the appropriate section (Features, Fixes, Chores) and is linked to the correct PR on GitHub

[ ]  Automated tests: All acceptance and unit tests are passing (yarn test)

[ ]  Manual tests (minimum tests should cover newly added feature/fix): App works correctly in development build (yarn dev)

[ ]  Manual tests (minimum tests should cover newly added feature/fix): App works correctly in production build (yarn package / CI builds)

[ ]  There are no flow errors or warnings (yarn flow:test)

[ ]  There are no lint errors or warnings (yarn lint)

[ ]  There are no prettier errors or warnings (yarn prettier:check)

[ ]  There are no missing translations (running yarn manage:translations produces no changes)

[ ]  Text changes are proofread and approved (Jane Wild / Amy Reeve)

[ ]  Japanese text changes are proofread and approved (Junko Oda)

[ ]  UI changes look good in all themes (Alexander Rukin)

[ ]  Storybook works and no stories are broken (yarn storybook)

[ ]  In case of dependency changes yarn.lock file is updated

Code Quality

[ ]  Important parts of the code are properly commented and documented
[ ]  Code is properly typed with flow
[ ]  React components are split-up enough to avoid unnecessary re-renderings
[ ]  Any code that only works in main process is neatly separated from components

Testing

[ ]  New feature/change is covered by acceptance tests
[ ]  New feature/change is manually tested and approved by QA team
[ ]  All existing acceptance tests are still up-to-date
[ ]  New feature/change is covered by Daedalus Testing scenario
[ ]  All existing Daedalus Testing scenarios are still up-to-date

After Review

[ ]  Merge the PR
[ ]  Delete the source branch
[ ]  Move the ticket to done column on the YouTrack board
[ ]  Update Slack QA thread by marking it with a green checkmark

@DeeJayElly why is "ada" in this context replaced with "ADA"? This is not correct. It should in "ADA" form ONLY when it is following a number - e.g. 100 ADA...

@nikolaglumac I reported this, my bad. I'll remove it from the card.
@DeeJayElly here are a few issues on this PR:

When accessing the "Redeem rewards" screen while Daedalus is syncing, a blank screen is displayed, instead of the corresponding message. Here is a recording.
The first validation message is still visible. Here is a screenshot. That was meant to be removed, the second validation is the one that should stay.

I have updated the PR with newest changes @gnpf @mioriohk

@DeeJayElly why is "ada" in this context replaced with "ADA"? This is not correct. It should in "ADA" form ONLY when it is following a number - e.g. 100 ADA...

@nikolaglumac I reported this, my bad. I'll remove it from the card.
@DeeJayElly here are a few issues on this PR:

When accessing the "Redeem rewards" screen while Daedalus is syncing, a blank screen is displayed, instead of the corresponding message. Here is a recording.
The first validation message is still visible. Here is a screenshot. That was meant to be removed, the second validation is the one that should stay.

I have updated the PR with newest fixes

@DeeJayElly  Issue summary:
New:

Regarding the second validation message: When the wallet has less than 10 ADA the validation message is displayed, but the user can proceed with the redemption (See recording here).
I think the value in which this message is displayed should be modified. We may need some clarification, but If I remember correctly, the wallet should have >= 1 ADA to cover the fees. Also if the message is displayed, the user should not be able to move to the next screen.

Fixed:

When accessing the "Redeem rewards" screen while Daedalus is syncing, a blank screen is displayed, instead of the corresponding message. Here is a recording.

The first validation message is still visible. Here is a screenshot. That was meant to be removed, the second validation is the one that should stay.

The "Syncing wallets" screen is not visible anymore when Daedalus is closed. Instead I observed a blank screen. I expected to see the "Stopping node/closing Daedalus" screen. Please see animated gif here

@DeeJayElly Issue summary:
New:

Regarding the second validation message: When the wallet has less than 10 ADA the validation message is displayed, but the user can proceed with the redemption (See recording here).
I think the value in which this message is displayed should be modified. We may need some clarification, but If I remember correctly, the wallet should have >= 1 ADA to cover the fees. Also if the message is displayed, the user should not be able to move to the next screen.

Fixed:

When accessing the "Redeem rewards" screen while Daedalus is syncing, a blank screen is displayed, instead of the corresponding message. Here is a recording.
The first validation message is still visible. Here is a screenshot. That was meant to be removed, the second validation is the one that should stay.
The "Syncing wallets" screen is not visible anymore when Daedalus is closed. Instead I observed a blank screen. I expected to see the "Stopping node/closing Daedalus" screen. Please see animated gif here

@gnpf should be all good now.

@DeeJayElly Here's the issue summary for 15009:
New:

When a syncing wallet is selected, the validation message that refers to the transaction fees is displayed. Here is a screenshot. There used to be a specific validation message for this scenario.

Pending

Regarding this issue:

I think the value in which this message is displayed should be modified. We may need some clarification, but If I remember correctly, the wallet should have >= 1 ADA to cover the fees. Also if the message is displayed, the user should not be able to move to the next screen.

I still think the value could be modified, 10 ADA seems too much to cover fees. Not sure how this was implemented before, but I think it was 1 ADA minimum to cover fees.
Fixed:

Regarding the second validation message: When the wallet has less than 10 ADA the validation message is displayed, but the user can proceed with the redemption (See recording here).

When accessing the "Redeem rewards" screen while Daedalus is syncing, a blank screen is displayed, instead of the corresponding message. Here is a recording.

The first validation message is still visible. Here is a screenshot. That was meant to be removed, the second validation is the one that should stay.

The "Syncing wallets" screen is not visible anymore when Daedalus is closed. Instead I observed a blank screen. I expected to see the "Stopping node/closing Daedalus" screen. Please see animated gif here

@DeeJayElly Here's the issue summary for 15009:
New:

When a syncing wallet is selected, the validation message that refers to the transaction fees is displayed. Here is a screenshot. There used to be a specific validation message for this scenario.

Pending

Regarding this issue:

I think the value in which this message is displayed should be modified. We may need some clarification, but If I remember correctly, the wallet should have >= 1 ADA to cover the fees. Also if the message is displayed, the user should not be able to move to the next screen.

I still think the value could be modified, 10 ADA seems too much to cover fees. Not sure how this was implemented before, but I think it was 1 ADA minimum to cover fees.
Fixed:

Regarding the second validation message: When the wallet has less than 10 ADA the validation message is displayed, but the user can proceed with the redemption (See recording here).
When accessing the "Redeem rewards" screen while Daedalus is syncing, a blank screen is displayed, instead of the corresponding message. Here is a recording.
The first validation message is still visible. Here is a screenshot. That was meant to be removed, the second validation is the one that should stay.
The "Syncing wallets" screen is not visible anymore when Daedalus is closed. Instead I observed a blank screen. I expected to see the "Stopping node/closing Daedalus" screen. Please see animated gif here

I have updated PR with new updates @mioriohk @ManusMcCole @gnpf

Hi @DeeJayElly , the following are my findings (Tested on build 15018.)
Fixed
When a syncing wallet is selected, the validation message that refers to the transaction fees is displayed. Here is a screenshot. There used to be a specific validation message for this scenario.
New issue
1 - When the wallets are being synced, choosing the first option doesn't display the expected error message. See here
2 - When the existing wallet has 1 ADA, upon clicking "Continue", error message displayed as "intl.formatMessage(error" and console errors seem to point to "not enough ada for fees". I expected this transaction to go through but it didn't. Please see here

Hi @DeeJayElly , the following are my findings (Tested on build 15018.)
Fixed
When a syncing wallet is selected, the validation message that refers to the transaction fees is displayed. Here is a screenshot. There used to be a specific validation message for this scenario.
New issues
1 - When the wallets are being synced, choosing the first option doesn't display the expected error message. See here
2 - When the existing wallet has 1 ADA, upon clicking "Continue", error message displayed as "intl.formatMessage(error)" and console errors seem to point to "not enough ada for fees". I expected this transaction to go through but it didn't. Please see here

@mioriohk 2. is fixed, while i can't reproduce 1. issue

@DeeJayElly On the build 15030:
New:

When selecting a syncing wallet, the wrong message is displayed. Here is a screenshot.

@mioriohk @ManusMcCole @gnpf New fixes are added, pls recheck newest build

@DeeJayElly On the build 15044:
New
1 - When the wallet is selected while syncing, no message is displayed. Here is a screenshot.
Pending:
1 - When the wallet has 1 ADA, the message of "insufficient ada" is displayed (after submission). The minimum was supposed to be 1 ADA. Here is a screenshot.
2 - As a continuation of the previous issue, when another wallet is selected, the message is not cleared. Here is a recording.
Fixed:
1 - When selecting a syncing wallet, the wrong message is displayed. Here is a screenshot.
2 - When the existing wallet has 1 ADA, upon clicking "Continue", error message displayed as "intl.formatMessage(error)" and console errors seem to point to "not enough ada for fees". I expected this transaction to go through but it didn't. Please see here
3 - I think the value in which this message is displayed should be modified. We may need some clarification, but If I remember correctly, the wallet should have >= 1 ADA to cover the fees. Also if the message is displayed, the user should not be able to move to the next screen
4 - Regarding the second validation message: When the wallet has less than 10 ADA the validation message is displayed, but the user can proceed with the redemption (See recording here).
5 - When accessing the "Redeem rewards" screen while Daedalus is syncing, a blank screen is displayed, instead of the corresponding message. Here is a recording.
6 - The first validation message is still visible. Here is a screenshot. That was meant to be removed, the second validation is the one that should stay.
7 - The "Syncing wallets" screen is not visible anymore when Daedalus is closed. Instead I observed a blank screen. I expected to see the "Stopping node/closing Daedalus" screen. Please see animated gif here

1 - When the wallet is selected while syncing, no message is displayed. Here is a screenshot.

@mioriohk @gnpf This is fixed.
1 - When the wallet is selected while syncing, no message is displayed. Here is a screenshot.

@DeeJayElly On build 15096:
New
1 - Two different minimum required ada for the same wallet displayed. The first time I selected a wallet with 0 ADA, the error message displayed that the minimum ada needed to be 1 ADA, but then, when I chose a wallet with 1 ADA, the minimum ada required changed to 1.174301 ADA (which was OK for this wallet). However, when I chose the wallet with 0 ADA again, the minimum required ada displayed at 1.174301 ADA. I believe error message requiring minimum of 1 ADA was wrong. See here
2 - When the ada that I had in a wallet was 1.174301, the error message displayed it required minimum ada of 1.174301.  I expected this not to display an error. See here
Fixed:
1 - When selecting a syncing wallet, the wrong message is displayed. Here is a screenshot.
2 - When the existing wallet has 1 ADA, upon clicking "Continue", error message displayed as "intl.formatMessage(error)" and console errors seem to point to "not enough ada for fees". I expected this transaction to go through but it didn't. Please see here
3 - I think the value in which this message is displayed should be modified. We may need some clarification, but If I remember correctly, the wallet should have >= 1 ADA to cover the fees. Also if the message is displayed, the user should not be able to move to the next screen
4 - Regarding the second validation message: When the wallet has less than 10 ADA the validation message is displayed, but the user can proceed with the redemption (See recording here).
5 - When accessing the "Redeem rewards" screen while Daedalus is syncing, a blank screen is displayed, instead of the corresponding message. Here is a recording.
6 - The first validation message is still visible. Here is a screenshot. That was meant to be removed, the second validation is the one that should stay.
7 - The "Syncing wallets" screen is not visible anymore when Daedalus is closed. Instead I observed a blank screen. I expected to see the "Stopping node/closing Daedalus" screen. Please see animated gif here
8 - When the wallet is selected while syncing, no message is displayed. Here is a screenshot.
9 - As a continuation of the previous issue, when another wallet is selected, the message is not cleared. Here is a recording.
Not relevant anymore
1 - When the wallet has 1 ADA, the message of "insufficient ada" is displayed (after submission). The minimum was supposed to be 1 ADA. Here is a screenshot.

@DeeJayElly Here's a summary for build 15105:
Pending:
1 - When selecting a wallet with no ada, the old message "1 ADA is required" is displayed. Here's a screenshot.
Fixed:
1 - When the ada that I had in a wallet was 1.174301, the error message displayed it required minimum ada of 1.174301.  I expected this not to display an error. See here
2 - I selected wallet with 0 ADA, the min required ada was displayed at 1.174301 ADA, then I selected another wallet. When I reselected the wallet with 0 ADA, the min ada required was now displayed at 2 ADA. See screenshot1 and screenshot2
3 - When selecting a syncing wallet, the wrong message is displayed. Here is a screenshot.
4 - When the existing wallet has 1 ADA, upon clicking "Continue", error message displayed as "intl.formatMessage(error)" and console errors seem to point to "not enough ada for fees". I expected this transaction to go through but it didn't. Please see here
5 - I think the value in which this message is displayed should be modified. We may need some clarification, but If I remember correctly, the wallet should have >= 1 ADA to cover the fees. Also if the message is displayed, the user should not be able to move to the next screen
6 - Regarding the second validation message: When the wallet has less than 10 ADA the validation message is displayed, but the user can proceed with the redemption (See recording here).
7 - When accessing the "Redeem rewards" screen while Daedalus is syncing, a blank screen is displayed, instead of the corresponding message. Here is a recording.
8 - The first validation message is still visible. Here is a screenshot. That was meant to be removed, the second validation is the one that should stay.
9 - The "Syncing wallets" screen is not visible anymore when Daedalus is closed. Instead I observed a blank screen. I expected to see the "Stopping node/closing Daedalus" screen. Please see animated gif here
10 - When the wallet is selected while syncing, no message is displayed. Here is a screenshot.
11 - As a continuation of the previous issue, when another wallet is selected, the message is not cleared. Here is a recording.
Not relevant anymore
1 - When the wallet has 1 ADA, the message of "insufficient ada" is displayed (after submission). The minimum was supposed to be 1 ADA. Here is a screenshot.

@gnpf why is this pending issue considered to be an issue? Didn’t we talk about this on the weekly call today? We need the wallet ti have at least one ada...

@DeeJayElly Addition to findings on build 15105 above.
(For the whole updated findings please refer to "Testing Summary":
Pending:
1 - When the ada that I had in a wallet was 1.174301, the error message displayed it required minimum ada of 1.174301.  I expected this not to display an error. See here. Also when I tried with another wallet with 1.175 ADA, I got message requiring 1.175 ADA. See here

Hi @DeeJayElly for build 15142, as per discussion:
Suggestion/Improvement
Please see Wallet with 1 ADA and Wallet with 1.165237 ADA I think the error message when the wallet has 1 ADA is misleading as it makes users think that they need a minimum of 1.165237 ADA in the wallet to claim ITN rewards, but when they try with wallet of 1.165237 ADA, the error displays  a minimum amount amount of 1.65413 ADA.

Hi @DeeJayElly for build 15142, as per discussion:
Suggestion/Improvement
Please see Wallet with 1 ADA and Wallet with 1.165237 ADA I think the error message when the wallet has 1 ADA is misleading as it makes users think that they need a minimum of 1.165237 ADA in the wallet to claim ITN rewards, but when they try with wallet of 1.165237 ADA, the error displays a minimum amount amount of 1.65413 ADA.

This is indeed unexpected. I believe both of these cases should NOT show error as clearly there is enough ada to cover fees...
@DeeJayElly please ping me in the morning to discuss this as it seems we did not understand each other. If a wallet has at least 1 ada that will be enough to cover fees - we just need to make sure to:

Show error for zero balance wallets
Allow redemption for wallets that have at least 1 ADA
Show correct fees for wallets that have ~1 ADA (e.g. if fees are ~0.17 ADA, then all wallets that have balances of between 1 and ~1.17 ADA will pay fees of 1 to ~1.17 ADA). Remember the table we have!

cc @gnpf @mioriohk

New:

Fees are incorrect for wallets with a balance between 1.17 and 2.1. Fees for these wallets are Total - 1, check this recording.

@DeeJayElly this definitely doesn't look right... :(

@DeeJayElly some findings for build 15345:
New:

For numbers with small decimal values (X.000001, X.001000) there is some error in the console and can't proceed to the next screen. Check this recording.
Not sure if this is expected, but sometimes the fee for wallets with balance >1000 is 1 ADA. It does not reproduce all the time. Could this be an issue? Check this recording.

Fixed:

Fees are incorrect for wallets with a balance between 1.17 and 2.1. Fees for these wallets are Total - 1.

@gnpf please show us the UTXO distribution for these wallets. This PR should be tested by using single UTXO wallets and I believe you are not doing that...

For numbers with small decimal values (X.000001, X.001000) there is some error in the console and can't proceed to the next screen. Check this recording.

@DeeJayElly please investigate this. It looks as if we are not using BigNumbers in all places correctly...

@gnpf please show us the UTXO distribution for these wallets. This PR should be tested by using single UTXO wallets and I believe you are not doing that...

@nikolaglumac Yesterday I made a few transactions on these wallets and I can't reproduce this issue now (the fees are correct now for those). This is the current UTXO distribution for that wallet.

@gnpf please show us the UTXO distribution for these wallets. This PR should be tested by using single UTXO wallets and I believe you are not doing that...

@nikolaglumac Yesterday I made a few transactions on these wallets after reporting this and I can't reproduce this issue now (the fees are correct now for those). This is the current UTXO distribution for that wallet.

@gnpf please re-run tests by using single UTXO wallets only 🙏

@DeeJayElly The followings are my current findings on build 15345 by using single UTXO wallets. Results are as expected so far (unless if you see something else which I could have missed):

@nikolaglumac
I have updated the PR with new updates:
After inspection of api endpoint path: /v2/wallets/${walletId}/payment-fees

We need to send Number as amount type, as API does not accept other types:

 amount: {
  quantity: amount,
  unit: WalletUnits.LOVELACE,
}

We are keeping formattedAmountToLovelace() in formatters while removing formattedAdaAmountToLovelace() as it's obsolete. That formatter is used on WalletSendForm component and also on RedeemRewards where we calculate fees.

@DeeJayElly For 15424 the last issue is fixed:

For numbers with small decimal values (X.000001, X.001000) there is some error in the console and can't proceed to the next screen. Check this recording.

The fee calculation is working well for all wallets, but sometimes an error is visible on the console when selecting a wallet. It's not very often, but I'm wondering if this could be an issue. If it's not relevant to this PR, I think this can be approved.

@DeeJayElly For 15424 the last issue is fixed:

For numbers with small decimal values (X.000001, X.001000) there is some error in the console and can't proceed to the next screen. Check this recording.

The fee calculation is working well for all wallets, but sometimes an error is visible on the console when selecting a wallet. It's not very often, but I'm wondering if this could be an issue. If it's not relevant to this PR, I think this can be approved.

Hi @gnpf can you isolate the specific moment when this error happens?

@DeeJayElly For 15424 the last issue is fixed:

For numbers with small decimal values (X.000001, X.001000) there is some error in the console and can't proceed to the next screen. Check this recording.

The fee calculation is working well for all wallets, but sometimes an error is visible on the console when selecting a wallet. It's not very often, but I'm wondering if this could be an issue. If it's not relevant to this PR, I think this can be approved.

I can not reproduce this @gnpf. Please try on a clean state again.

@DeeJayElly please rename isRecoveryPhaseSet to isRewardsRedemptionRequest

Done

Please change to:

// Amount is set to either wallet's balance in case balance is less than 3 ADA or 1 ADA in order to avoid min UTXO affecting transaction fees calculation

Done

@DeeJayElly please rename REWARDS_REDEEM_RECEIVER_AMOUNT  to REWARDS_REDEMPTION_FEE_CALCULATION_AMOUNT

Done

@DeeJayElly I tested the new build on a clean state. Regarding the error on the console:

I tried with 32 wallets multiple times and the error was displayed 3 times.
It was displayed when the wallet was selected on the combo (after the spinner disappears).
All these wallets have different balances and a single UTXO.
I repeat the tests many times with the wallets that received an error and it didn't reproduce.
Also, the fee calculation is correct, even when the error is displayed.

I don't think this is too critical as it doesn't happen all the time and the fee calculation is apparently not affected, but I'd like to know what you think.

@DeeJayElly I tested the new build on a clean state. Regarding the error on the console:

I tried with 32 wallets multiple times and the error was displayed 3 times.
It was displayed when the wallet was selected on the combo (after the spinner disappears).
All these wallets have different balances and a single UTXO.
I repeat the tests many times with the wallets that received an error and it didn't reproduce.
Also, the fee calculation is correct, even when the error is displayed.

I don't think this is too critical as it doesn't happen all the time and the fee calculation is apparently not affected, but I'd like to know what you think.

@gnpf this is not connected to this PR - it is your local machine issue it seems.

@DeeJayElly I tested the new build on a clean state. Regarding the error on the console:

I tried with 32 wallets multiple times and the error was displayed 3 times.
It was displayed when the wallet was selected on the combo (after the spinner disappears).
All these wallets have different balances and a single UTXO.
I repeat the tests many times with the wallets that received an error and it didn't reproduce.
Also, the fee calculation is correct, even when the error is displayed.

I don't think this is too critical as it doesn't happen all the time and the fee calculation is apparently not affected, but I'd like to know what you think.

@gnpf Thank you for clarifying, but i think this is not related to this task.


mgmt, regen trafficmanager

Description
Please add an informative description that covers that changes made by the pull request and link all relevant issues.
If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
All SDK Contribution checklist:

[ ] The pull request does not introduce [breaking changes]
[ ] CHANGELOG is updated for new features, bug fixes or other significant changes.
[ ] I have read the contribution guidelines.

General Guidelines and Best Practices

[ ] Title of the pull request is clear and informative.
[ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[ ] Pull request includes test coverage for the included changes.

test the latest codegen (there is some difference of API in fluent package)
regen for samples

API change check
API changes are not detected in this pull request.

live tests passed


[UPDATED] Enhanced Login Page UI

Description

Enhanced the UI of login Page
Changed color of form-container
Made Social Icons Clickable

Fixes #70

This PR is created in reference to Issue No.: #70

Screenshots

Checklist

[x] Tests have been added or updated to cover the changes
[x] Documentation has been updated to reflect the changes
[x] Code follows the established coding style guidelines
[x] All tests are passing

@Mahitej28  Wow, I must say, you've done an outstanding job redesigning the page! The improvements you've made are truly remarkable. The layout is now much more visually appealing and user-friendly.
But we have redesigned the login and signup page with both mobile as well as desktop view.
Can you check out the new design once?

@omkarguravv you would have let me know once so that I would had worked accordingly

@Mahitej28  Checkout #145
Make Sure to join Discord server and Slack Channel for latest updates.

Ok so what should I do now further ?

Similar issue is being raised #145 you can work on it , no further changes will be done in new design template you can work on it.

Ok


Add Z forward option to PathFollow3D

Prerequisite #72842.
This option is needed since PathFollow3D has the forward vector hardcoded inside it.

Integrated to https://github.com/godotengine/godot/pull/72842.


Service Hooks ip addresses not working with Azure Storage Queue restrictions

Based on the documentation, "Azure DevOps Services connecting to endpoints for Service Hooks" is listed under the Inbound connections. When we listed all of those addresses to Azure Storage Networking Firewall list, we get "Not Authorized" when testing connection to put message to storage queue. When allowing access from All networks in storage, the connection works. So this list or documentation has to be incomplete.

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

ID: dc5a4cfa-aa84-9f0f-55f4-71ec4861c070
Version Independent ID: d621620a-c924-03b1-8b43-f99c33e58bb8
Content: Add IP addresses and URLs to allow list - Azure DevOps
Content Source: docs/organizations/security/allow-list-ip-url.md
Product: devops
Technology: devops-security
GitHub Login: @chcomley
Microsoft Alias: chcomley

Hi @PekkaJalonen, I wanted to give you an update on this, sorry for the delay, but I've engaged a PM and am awaiting feedback. Please stay tuned. Thanks so much for reaching out.

I've updated the article. This issue will automatically close, once the PR closes. Here's a link to some more information that might be helpful, thank you! Configure Azure Storage firewalls and virtual networks


Comments

I don't know if this is a serious issue for many, but I've found that the comments' contrast with the background makes them very hard to read and after awhile hurts my eyes. I love this theme, but my only suggestion is to edit the comment colors from the previous value of #5C367085, to remove the alpha channel for a new value #5C3670:
...
"tokenColors" : [
  ...
  {
    "name": "Comments",
    "scope": "comment, punctuation.definition.comment",
      "settings": {
        "foreground": "#5C6370",
        "fontStyle": "italic"
      }
  },
  ...
],
...

It doesn't break the style of the theme, in my opinion, and makes it much more readable due to the increased contrast. Thank you.

@jsbUSMC I don't have any issues with that - though it looks like that you've got a purplish color for the comments -

@jsbUSMC looking at them side-by-side I'll have to agree with you.

Appreciate that you've caught the typo! Thank you for your feedback!


Update doobie-core, doobie-hikari, ... to 0.13.0

Updates

org.tpolecat:doobie-core
org.tpolecat:doobie-hikari
org.tpolecat:doobie-postgres

from 0.12.1 to 0.13.0.
GitHub Release Notes - Changelog - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.tpolecat" } ]

labels: library-update, semver-minor

Superseded by #362.


22/03/20 21:59:24 INFO AbstractHoodieLogRecordReader: Reading a data block from file file:/tmp/hudi_4635/.hoodie/metadata/files/.files-0000_20220320215907162001.log.2_0-991-2273 at instant<PHONE_NUMBER>5909174
22/03/20 21:59:24 INFO AbstractHoodieLogRecordReader: Number of remaining logblocks to merge 1
22/03/20 21:59:24 INFO CacheConfig: Created cacheConfig: blockCache=LruBlockCache{blockCount=0, currentSize=392960, freeSize=381498432, maxSize=381891392, heapSize=392960, minSize=362796832, minFactor=0.95, multiSize=181398416, multiFactor=0.5, singleSize=90699208, singleFactor=0.25}, cacheDataOnRead=true, cacheDataOnWrite=false, cacheIndexesOnWrite=false, cacheBloomsOnWrite=false, cacheEvictOnClose=false, cacheDataCompressed=false, prefetchOnOpen=false
22/03/20 21:59:24 INFO CodecPool: Got brand-new decompressor [.gz]
22/03/20 21:59:24 INFO CodecPool: Got brand-new decompressor [.gz]
22/03/20 21:59:24 INFO CodecPool: Got brand-new decompressor [.gz]
22/03/20 21:59:24 INFO CodecPool: Got brand-new decompressor [.gz]
22/03/20 21:59:24 INFO ExternalSpillableMap: Estimated Payload size => 616
22/03/20 21:59:24 INFO AbstractHoodieLogRecordReader: Merging the final data blocks
22/03/20 21:59:24 INFO AbstractHoodieLogRecordReader: Number of remaining logblocks to merge 1
22/03/20 21:59:24 INFO CacheConfig: Created cacheConfig: blockCache=LruBlockCache{blockCount=0, currentSize=392960, freeSize=381498432, maxSize=381891392, heapSize=392960, minSize=362796832, minFactor=0.95, multiSize=181398416, multiFactor=0.5, singleSize=90699208, singleFactor=0.25}, cacheDataOnRead=true, cacheDataOnWrite=false, cacheIndexesOnWrite=false, cacheBloomsOnWrite=false, cacheEvictOnClose=false, cacheDataCompressed=false, prefetchOnOpen=false
22/03/20 21:59:24 INFO CodecPool: Got brand-new decompressor [.gz]
22/03/20 21:59:24 INFO CodecPool: Got brand-new decompressor [.gz]
22/03/20 21:59:24 INFO CodecPool: Got brand-new decompressor [.gz]
22/03/20 21:59:24 INFO CodecPool: Got brand-new decompressor [.gz]
22/03/20 21:59:24 INFO HoodieMergedLogRecordScanner: Number of log files scanned => 2
22/03/20 21:59:24 INFO HoodieMergedLogRecordScanner: MaxMemoryInBytes allowed for compaction =><PHONE_NUMBER>
22/03/20 21:59:24 INFO HoodieMergedLogRecordScanner: Number of entries in MemoryBasedMap in ExternalSpillableMap => 3
22/03/20 21:59:24 INFO HoodieMergedLogRecordScanner: Total size in bytes of MemoryBasedMap in ExternalSpillableMap => 1848
22/03/20 21:59:24 INFO HoodieMergedLogRecordScanner: Number of entries in BitCaskDiskMap in ExternalSpillableMap => 0
22/03/20 21:59:24 INFO HoodieMergedLogRecordScanner: Size of file spilled to disk => 0
22/03/20 21:59:24 INFO HoodieBackedTableMetadata: Opened 2 metadata log files (dataset instant=20220320215909174, metadata instant=20220320215909174) in 36 ms
22/03/20 21:59:24 INFO CodecPool: Got brand-new decompressor [.gz]
22/03/20 21:59:24 INFO BaseTableMetadata: Listed file in partition from metadata: partition=GEF/20211215, #files=9
22/03/20 21:59:24 INFO BaseTableMetadata: Listed file in partition from metadata: partition=HEF/20211215, #files=9
22/03/20 21:59:24 INFO BaseTableMetadata: Listed file in partition from metadata: partition=FEF/20211215, #files=9
22/03/20 21:59:24 INFO BaseTableMetadata: Listed file in partition from metadata: partition=EEF/20211215, #files=9
22/03/20 21:59:24 INFO BaseTableMetadata: Listed file in partition from metadata: partition=DEF/20211215, #files=10
22/03/20 21:59:24 INFO AbstractTableFileSystemView: addFilesToView: NumFiles=9, NumFileGroups=9, FileGroupsCreationTime=0, StoreTimeTaken=0
22/03/20 21:59:24 INFO AbstractTableFileSystemView: addFilesToView: NumFiles=9, NumFileGroups=9, FileGroupsCreationTime=0, StoreTimeTaken=0
22/03/20 21:59:24 INFO AbstractTableFileSystemView: addFilesToView: NumFiles=9, NumFileGroups=9, FileGroupsCreationTime=1, StoreTimeTaken=0
22/03/20 21:59:24 INFO AbstractTableFileSystemView: addFilesToView: NumFiles=9, NumFileGroups=9, FileGroupsCreationTime=1, StoreTimeTaken=0
22/03/20 21:59:24 INFO AbstractTableFileSystemView: addFilesToView: NumFiles=10, NumFileGroups=10, FileGroupsCreationTime=1, StoreTimeTaken=0
22/03/20 21:59:24 INFO RemoteHoodieTableFileSystemView: Sending request : (http://rkalluri.attlocal.net:63594/v1/hoodie/view/filegroups/all/partition/?partition=GEF%2F20211215&basepath=file%3A%2Ftmp%2Fhudi_4635&lastinstantts=20220320215909174&timelinehash=6d633da951dc97b80f9b1ab40bb28007857d183169e822cc8b2d05907b903876)
22/03/20 21:59:24 INFO RemoteHoodieTableFileSystemView: Sending request : (http://rkalluri.attlocal.net:63594/v1/hoodie/view/filegroups/all/partition/?partition=FEF%2F20211215&basepath=file%3A%2Ftmp%2Fhudi_4635&lastinstantts=20220320215909174&timelinehash=6d633da951dc97b80f9b1ab40bb28007857d183169e822cc8b2d05907b903876)
22/03/20 21:59:24 INFO RemoteHoodieTableFileSystemView: Sending request : (http://rkalluri.attlocal.net:63594/v1/hoodie/view/filegroups/all/partition/?partition=DEF%2F20211215&basepath=file%3A%2Ftmp%2Fhudi_4635&lastinstantts=20220320215909174&timelinehash=6d633da951dc97b80f9b1ab40bb28007857d183169e822cc8b2d05907b903876)
22/03/20 21:59:24 INFO RemoteHoodieTableFileSystemView: Sending request : (http://rkalluri.attlocal.net:63594/v1/hoodie/view/filegroups/all/partition/?partition=EEF%2F20211215&basepath=file%3A%2Ftmp%2Fhudi_4635&lastinstantts=20220320215909174&timelinehash=6d633da951dc97b80f9b1ab40bb28007857d183169e822cc8b2d05907b903876)
22/03/20 21:59:24 INFO RemoteHoodieTableFileSystemView: Sending request : (http://rkalluri.attlocal.net:63594/v1/hoodie/view/filegroups/all/partition/?partition=HEF%2F20211215&basepath=file%3A%2Ftmp%2Fhudi_4635&lastinstantts=20220320215909174&timelinehash=6d633da951dc97b80f9b1ab40bb28007857d183169e822cc8b2d05907b903876)
22/03/20 21:59:24 INFO CleanPlanner: 0 patterns used to delete in partition path:DEF/20211215
22/03/20 21:59:24 INFO CleanPlanner: 0 patterns used to delete in partition path:GEF/20211215
22/03/20 21:59:24 INFO CleanPlanner: 0 patterns used to delete in partition path:EEF/20211215
22/03/20 21:59:24 INFO Executor: Finished task 0.0 in stage 999.0 (TID 2279). 931 bytes result sent to driver
22/03/20 21:59:24 INFO Executor: Finished task 3.0 in stage 999.0 (TID 2282). 931 bytes result sent to driver
22/03/20 21:59:24 INFO CleanPlanner: 0 patterns used to delete in partition path:HEF/20211215
22/03/20 21:59:24 INFO Executor: Finished task 1.0 in stage 999.0 (TID 2280). 931 bytes result sent to driver
22/03/20 21:59:24 INFO CleanPlanner: 0 patterns used to delete in partition path:FEF/20211215
22/03/20 21:59:24 INFO Executor: Finished task 4.0 in stage 999.0 (TID 2283). 931 bytes result sent to driver
22/03/20 21:59:24 INFO TaskSetManager: Finished task 0.0 in stage 999.0 (TID 2279) in 125 ms on rkalluri.attlocal.net (executor driver) (1/5)
22/03/20 21:59:24 INFO TaskSetManager: Finished task 3.0 in stage 999.0 (TID 2282) in 125 ms on rkalluri.attlocal.net (executor driver) (2/5)
22/03/20 21:59:24 INFO Executor: Finished task 2.0 in stage 999.0 (TID 2281). 931 bytes result sent to driver
22/03/20 21:59:24 INFO TaskSetManager: Finished task 1.0 in stage 999.0 (TID 2280) in 125 ms on rkalluri.attlocal.net (executor driver) (3/5)
22/03/20 21:59:24 INFO TaskSetManager: Finished task 4.0 in stage 999.0 (TID 2283) in 125 ms on rkalluri.attlocal.net (executor driver) (4/5)
22/03/20 21:59:24 INFO TaskSetManager: Finished task 2.0 in stage 999.0 (TID 2281) in 125 ms on rkalluri.attlocal.net (executor driver) (5/5)
22/03/20 21:59:24 INFO TaskSchedulerImpl: Removed TaskSet 999.0, whose tasks have all completed, from pool
22/03/20 21:59:24 INFO DAGScheduler: ResultStage 999 (collect at HoodieSparkEngineContext.java:100) finished in 0.213 s
22/03/20 21:59:24 INFO DAGScheduler: Job 690 is finished. Cancelling potential speculative or zombie tasks for this job
22/03/20 21:59:24 INFO TaskSchedulerImpl: Killing all running tasks in stage 999: Stage finished
22/03/20 21:59:24 INFO DAGScheduler: Job 690 finished: collect at HoodieSparkEngineContext.java:100, took 0.213358 s
22/03/20 21:59:24 INFO HoodieActiveTimeline: Loaded instants upto : Option{val=[20220320215909174__commit__COMPLETED]}
22/03/20 21:59:24 INFO BaseHoodieWriteClient: Start to archive synchronously.
22/03/20 21:59:24 INFO HoodieActiveTimeline: Loaded instants upto : Option{val=[20220320215909174__commit__COMPLETED]}
22/03/20 21:59:24 INFO HoodieTableMetaClient: Loading HoodieTableMetaClient from file:///tmp/hudi_4635
22/03/20 21:59:24 INFO HoodieTableConfig: Loading table properties from file:/tmp/hudi_4635/.hoodie/hoodie.properties
22/03/20 21:59:24 INFO HoodieTableMetaClient: Finished Loading Table of type COPY_ON_WRITE(version=1, baseFileFormat=PARQUET) from file:///tmp/hudi_4635
22/03/20 21:59:24 INFO HoodieTableMetaClient: Loading HoodieTableMetaClient from file:///tmp/hudi_4635/.hoodie/metadata
22/03/20 21:59:24 INFO HoodieTableConfig: Loading table properties from file:/tmp/hudi_4635/.hoodie/metadata/.hoodie/hoodie.properties
22/03/20 21:59:24 INFO HoodieTableMetaClient: Finished Loading Table of type MERGE_ON_READ(version=1, baseFileFormat=HFILE) from file:///tmp/hudi_4635/.hoodie/metadata
22/03/20 21:59:24 INFO HoodieActiveTimeline: Loaded instants upto : Option{val=[20220320215909174__deltacommit__COMPLETED]}
22/03/20 21:59:24 INFO HoodieTimelineArchiver: Limiting archiving of instants to latest compaction on metadata table at<PHONE_NUMBER>5907162001
22/03/20 21:59:24 INFO HoodieHeartbeatClient: Stopping heartbeat for instant<PHONE_NUMBER>5909174
22/03/20 21:59:24 INFO HoodieHeartbeatClient: Stopped heartbeat for instant<PHONE_NUMBER>5909174
22/03/20 21:59:24 INFO HeartbeatUtils: Deleted the heartbeat for instant<PHONE_NUMBER>5909174
22/03/20 21:59:24 INFO HoodieHeartbeatClient: Deleted heartbeat file for instant<PHONE_NUMBER>5909174
22/03/20 21:59:24 INFO TransactionManager: Transaction ending with transaction owner Option{val=[==>20220320215909174__commit__INFLIGHT]}
22/03/20 21:59:24 INFO ZookeeperBasedLockProvider: RELEASING lock atZkBasePath = /hudi, lock key = None
22/03/20 21:59:24 INFO ZookeeperBasedLockProvider: RELEASED lock atZkBasePath = /hudi, lock key = None
22/03/20 21:59:24 INFO TransactionManager: Transaction ended with transaction owner Option{val=[==>20220320215909174__commit__INFLIGHT]}
An error occurred while calling o1843.save.
: java.lang.NullPointerException
at org.apache.hudi.client.HoodieTimelineArchiver.lambda$getInstantsToArchive$10(HoodieTimelineArchiver.java:452)
at java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:267)
at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at java.util.stream.SliceOps$1$1.accept(SliceOps.java:204)
at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at java.util.ArrayList$ArrayListSpliterator.tryAdvance(ArrayList.java:1351)
at java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:126)
at java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:498)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:485)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at java.util.stream.StreamSpliterators$WrappingSpliterator.forEachRemaining(StreamSpliterators.java:312)
at java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:743)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
at org.apache.hudi.client.HoodieTimelineArchiver.archiveIfRequired(HoodieTimelineArchiver.java:147)
at org.apache.hudi.client.BaseHoodieWriteClient.archive(BaseHoodieWriteClient.java:818)
at org.apache.hudi.client.BaseHoodieWriteClient.autoArchiveOnCommit(BaseHoodieWriteClient.java:572)
at org.apache.hudi.client.BaseHoodieWriteClient.postCommit(BaseHoodieWriteClient.java:477)
at org.apache.hudi.client.BaseHoodieWriteClient.commitStats(BaseHoodieWriteClient.java:212)
at org.apache.hudi.client.SparkRDDWriteClient.commit(SparkRDDWriteClient.java:119)
at org.apache.hudi.HoodieSparkSqlWriter$.commitAndPerformPostOperations(HoodieSparkSqlWriter.scala:667)
at org.apache.hudi.HoodieSparkSqlWriter$.write(HoodieSparkSqlWriter.scala:299)
at org.apache.hudi.DefaultSource.createRelation(DefaultSource.scala:162)
at org.apache.spark.sql.execution.datasources.SaveIntoDataSourceCommand.run(SaveIntoDataSourceCommand.scala:45)
at org.apache.spark.sql.execution.command.ExecutedCommandExec.sideEffectResult$lzycompute(commands.scala:75)
at org.apache.spark.sql.execution.command.ExecutedCommandExec.sideEffectResult(commands.scala:73)
at org.apache.spark.sql.execution.command.ExecutedCommandExec.executeCollect(commands.scala:84)
at org.apache.spark.sql.execution.QueryExecution$$anonfun$eagerlyExecuteCommands$1.$anonfun$applyOrElse$1(QueryExecution.scala:110)
at org.apache.spark.sql.execution.SQLExecution$.$anonfun$withNewExecutionId$5(SQLExecution.scala:103)
at org.apache.spark.sql.execution.SQLExecution$.withSQLConfPropagated(SQLExecution.scala:163)
at org.apache.spark.sql.execution.SQLExecution$.$anonfun$withNewExecutionId$1(SQLExecution.scala:90)
at org.apache.spark.sql.SparkSession.withActive(SparkSession.scala:775)
at org.apache.spark.sql.execution.SQLExecution$.withNewExecutionId(SQLExecution.scala:64)
at org.apache.spark.sql.execution.QueryExecution$$anonfun$eagerlyExecuteCommands$1.applyOrElse(QueryExecution.scala:110)
at org.apache.spark.sql.execution.QueryExecution$$anonfun$eagerlyExecuteCommands$1.applyOrElse(QueryExecution.scala:106)
at org.apache.spark.sql.catalyst.trees.TreeNode.$anonfun$transformDownWithPruning$1(TreeNode.scala:481)
at org.apache.spark.sql.catalyst.trees.CurrentOrigin$.withOrigin(TreeNode.scala:82)
at org.apache.spark.sql.catalyst.trees.TreeNode.transformDownWithPruning(TreeNode.scala:481)
at org.apache.spark.sql.catalyst.plans.logical.LogicalPlan.org$apache$spark$sql$catalyst$plans$logical$AnalysisHelper$$super$transformDownWithPruning(LogicalPlan.scala:30)
at org.apache.spark.sql.catalyst.plans.logical.AnalysisHelper.transformDownWithPruning(AnalysisHelper.scala:267)
at org.apache.spark.sql.catalyst.plans.logical.AnalysisHelper.transformDownWithPruning$(AnalysisHelper.scala:263)
at org.apache.spark.sql.catalyst.plans.logical.LogicalPlan.transformDownWithPruning(LogicalPlan.scala:30)
at org.apache.spark.sql.catalyst.plans.logical.LogicalPlan.transformDownWithPruning(LogicalPlan.scala:30)
at org.apache.spark.sql.catalyst.trees.TreeNode.transformDown(TreeNode.scala:457)
at org.apache.spark.sql.execution.QueryExecution.eagerlyExecuteCommands(QueryExecution.scala:106)
at org.apache.spark.sql.execution.QueryExecution.commandExecuted$lzycompute(QueryExecution.scala:93)
at org.apache.spark.sql.execution.QueryExecution.commandExecuted(QueryExecution.scala:91)
at org.apache.spark.sql.execution.QueryExecution.assertCommandExecuted(QueryExecution.scala:128)
at org.apache.spark.sql.DataFrameWriter.runCommand(DataFrameWriter.scala:848)
at org.apache.spark.sql.DataFrameWriter.saveToV1Source(DataFrameWriter.scala:382)
at org.apache.spark.sql.DataFrameWriter.saveInternal(DataFrameWriter.scala:355)
at org.apache.spark.sql.DataFrameWriter.save(DataFrameWriter.scala:247)
at sun.reflect.GeneratedMethodAccessor224.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at py4j.reflection.MethodInvoker.invoke(MethodInvoker.java:244)
at py4j.reflection.ReflectionEngine.invoke(ReflectionEngine.java:357)
at py4j.Gateway.invoke(Gateway.java:282)
at py4j.commands.AbstractCommand.invokeMethod(AbstractCommand.java:132)
at py4j.commands.CallCommand.execute(CallCommand.java:79)
at py4j.ClientServerConnection.waitForCommands(ClientServerConnection.java:182)
at py4j.ClientServerConnection.run(ClientServerConnection.java:106)
at java.lang.Thread.run(Thread.java:745)
22/03/20 21:59:24 INFO SparkContext: Invoking stop() from shutdown hook
22/03/20 21:59:24 INFO SparkUI: Stopped Spark web UI at http://rkalluri.attlocal.net:4040
22/03/20 21:59:24 INFO MapOutputTrackerMasterEndpoint: MapOutputTrackerMasterEndpoint stopped!
22/03/20 21:59:24 INFO MemoryStore: MemoryStore cleared
22/03/20 21:59:24 INFO BlockManager: BlockManager stopped
22/03/20 21:59:24 INFO BlockManagerMaster: BlockManagerMaster stopped
22/03/20 21:59:24 INFO OutputCommitCoordinator$OutputCommitCoordinatorEndpoint: OutputCommitCoordinator stopped!
22/03/20 21:59:24 INFO SparkContext: Successfully stopped SparkContext
22/03/20 21:59:24 INFO ShutdownHookManager: Shutdown hook called

sorry. could not get time to repro this. I don't have exp w/ pyspark. I just saved the script to rep.py and tried to execute the spark-submit. but running into failures.
:: resolution report :: resolve 255ms :: artifacts dl 5ms
	:: modules in use:
	org.apache.hudi#hudi-spark-bundle_2.11;0.10.1 from local-m2-cache in [default]
	org.apache.spark#spark-avro_2.11;2.4.4 from local-m2-cache in [default]
	org.spark-project.spark#unused;1.0.0 from local-m2-cache in [default]
	---------------------------------------------------------------------
	|                  |            modules            ||   artifacts   |
	|       conf       | number| search|dwnlded|evicted|| number|dwnlded|
	---------------------------------------------------------------------
	|      default     |   3   |   0   |   0   |   0   ||   3   |   0   |
	---------------------------------------------------------------------
:: retrieving :: org.apache.spark#spark-submit-parent-a3077db6-05fc-4539-ab07-7fcdba4e85ba
	confs: [default]
	0 artifacts copied, 3 already retrieved (0kB/5ms)
22/03/19 14:05:28 WARN Utils: Your hostname, Sivabalans-MacBook-Pro.local resolves to a loopback address: <IP_ADDRESS>; using <IP_ADDRESS> instead (on interface en0)
22/03/19 14:05:28 WARN Utils: Set SPARK_LOCAL_IP if you need to bind to another address
22/03/19 14:05:28 WARN NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
  File "/tmp/rep.py", line 26
    'hoodie.write.lock.zookeeper.lock_key': f"{table_name}",
                                                          ^
SyntaxError: invalid syntax
log4j:WARN No appenders could be found for logger (org.apache.spark.util.ShutdownHookManager).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.

Or should I launch pyspark and run through the commands you have given above.

yeah, please launch pyspark and try.

We have identified an issue w/ multi-writer wrt archival resulting in NPE and the fix is here. If you can give it a try and let us know, if it works, would be great.

https://github.com/apache/hudi/pull/5138
closing this as we have landed a fix. please re-open or open a new issue if you encounter any new issues


Jest and Orbit issue

Orbity keystore depends on elliptic which depends on the brorand library. When running Jest tests with  --env=jsdom, the brorand library throws an error.
jsdom lacks crypto: https://github.com/jsdom/jsdom/issues/1612. As a result, brorand/index (lines 30-50) looks for self.crypto and doesn't find it, concludes that we are on Safari, and throws an error.
This error can be avoided in one of two ways (so far): (1) Use node as the environment. (2) Install a monkey patch before the environment is set up (in a config file, not in the test file), like this:
import crypto from 'crypto';
self.crypto = crypto;
self.crypto.getRandomValues = (arr) => {
  crypto.randomBytes(arr.length);
};

This is really a Jest/jsdom issue but thought I'd document here for posterity!

There is an open PR for brorand about this (https://github.com/indutny/brorand/pull/5) but it's been stuck there for years now

If anyone needs a quickfix for that:
const crypto = require('crypto');
Object.defineProperty(global.self, 'crypto', {
  value: {
    getRandomValues: arr => crypto.randomBytes(arr.length),
  },
});

And then passing it to jest config should work:
"jest": {
    "setupFiles": ["fixCrypto.js"]
}

Fix provided by @thiagodelgado111 . Closing for now.


Fix CI build

Since switching to vert.x 3 support, the travis CI build is broken, due to lack of configuration for the maven deploy plugin.
Refit the original configuration for this plugin.

Needed to set the parent pom correctly - this has now been done.


Bug: Look into image srcset/sizes optimization and see if it can play better with animations

Marian shared these two screencasts of the image behaving weirdly (jumpy/flickery) in an animation. I believe this is AMP doing some srcset & sizes optimization and we're just seeing progressively better quality images load when they're first rendered.
This is an exploratory task to see if there's anyway we can mitigate this on our end, that being said it may ultimately just be a byproduct of the approach amp uses to optimize images (which is a good approach and is necessary).
Anyway, gonna set this as a 3 pointer to time box this as it has the potential to be a rabbit hole of a task.
https://images.zenhubusercontent.com/235435637/da2abbd9-05cb-401b-9ce2-a8c244bd03d5/fg_scalein_batch2_story4_page01.mov
https://images.zenhubusercontent.com/235435637/8fe3cdd6-b241-4a0a-87ba-d5435b6a0832/fg_scalein_batch2_story3_page07.mov

@csossi - there's testing directions in the PR :)

Which plugin version was this tested with?

I believe this is AMP doing some srcset & sizes optimization and we're just seeing progressively better quality images load when they're first rendered.

Worth noting that we just implemented some significant changes to sizes logic in #8099 that fixed a long-standing issue with blurry images when viewing stories.
Most certainly this will have an affect on this behavior reported here as well.
So if this was tested under v1.8.0, I highly recommend testing again, as it might have been fixed already by this change.

Verified in QA


basePath not used in resource requests

First i'd like to say thank you for your great work.
I think i found a serious bug. When setting the "basePath" parameter to include a directory e.g. http://myapp.com/v1/ - all the requests for css, js etc still go to http://myapp.com/ skipping the "v1/" path.
Or do i need to configure something else to make it available in such a scenario?
thanks & kind regards,
Chris

Hi Chris
Sorry its taken a while to get back to you.  The basePath property is the URL of the site which provides the API. Its needed by Swagger to construct paths for the API calls and as you found out it is also used to path the plug-in CSS and JS directories.
It should include the protocol, host and any port number  i.e. http://localhost:3000. You should not add the path element of URL into basePath property
I think the naming of this property basePath is a bit confusing but is taken directly form the Swagger spec. Maybe they should of called it baseURL or baseProtocolHost
If your API has a path with a number of segments i.e. http://localhost:3000/api/v1/users and which you do not wish to be displayed  i.e. api/v1  in the Swagger interface you can play with the 'pathPrefixSize' number.
Hope the above helps

Hi,
Thanks for the explaination i'll try out and let you know if it workes in my case.
My requirement is not to "hide" the path from the swagger ui.
We are running a load ballancer that is doing URL rewrites in order to server different API version from one endpoint so - p.e.
GET /dev/users/1 -> gets transalted to http://api.devserver.int/users/1
GET /v1/users/1 -> gets transalted to http://api.v1.productionserver.int/users/1
thx & kind regards,
Christian

@theanimal666 did u find the solution for this?


How to send multiple query strings to Algolia for search in multiple fields

I don't know if this is already possible with algolia, but the docs didn't help. Can I make queries , specifying multiple search queries for different fields in my objects ? For example, I want my users to type in a pickup address, and a drop off address . Can I ask algolia to search for the records where pickup address match with query string for pickup , and the drop off address matches the query string for drop off ? Is this possible ? Thank you for an enlightenment !

Hi @kati-frantz, this is not a particular issue of the JavaScript client but more of a generic question on how to use Algolia to do X.
I would advise you to post this question, with a bit more context on what you are building and what you would want to use Algolia for, on our discourse forum: https://discourse.algolia.com/c/development
Thanks a lot!


[HELP] How to show sidebar in 'post' pages?

main index.html ==> default : show sidebar
but 'post' page ==> default : hide sidebar
I want to show sidebar in posts.
How to change default view?
thx.

you can add this configuration in your theme _config.yaml file:
close_aside: false  #close sidebar in post page if true

It was not working.
I think this function doesn't suit Jekyll. :(
THX anyway.

@DebugNote  what theme are you using?


Events::AUTHENTICATION_SUCCESS - Adding public data to the JWT response

Hi,
i´m trying to add a custom public data to the JWT response and when i follow the instructions for my symfony instalation i´m getting the following message:

(2/2) FileLoaderLoadExceptionThe autoloader expected class "App\EventListener\AuthenticationEventListener" to be defined in file "/Users/fjugaldev/Sites/sftest/civination-backend/vendor/composer/../../src/EventListener/AuthenticationEventListener.php". The file was found but the class was not in it, the class name or namespace probably has a typo in /Users/fjugaldev/Sites/sftest/civination-backend/config/services.yaml (which is loaded in resource "/Users/fjugaldev/Sites/sftest/civination-backend/config/services.yaml").

My services.yml looks like:
acme_api.event.authentication_success_listener:
        class: AppBundle\EventListener\AuthenticationSuccessListener
        tags:
            - { name: kernel.event_listener, event: lexik_jwt_authentication.on_authentication_success, method: onAuthenticationSuccessResponse }

And the class for this service:
use Lexik\Bundle\JWTAuthenticationBundle\Event\AuthenticationSuccessEvent;

/**
 * @param AuthenticationSuccessEvent $event
 */
public function onAuthenticationSuccessResponse(AuthenticationSuccessEvent $event)
{
    $data = $event->getData();
    $user = $event->getUser();

    if (!$user instanceof UserInterface) {
        return;
    }

    $data['data'] = array(
        'roles' => $user->getRoles(),
    );

    $event->setData($data);
}

I'm doing everything just like the documentation says.
The next thing i tried is to define the service like this:
App\EventListener\AuthenticationSuccessListener:
        tags:
            - { name: kernel.event_listener, event: lexik_jwt_authentication.on_authentication_success, method: onAuthenticationSuccessResponse }

But still throwing the same error. I´m using Symfony 4.
Anybody has any idea?
Thanks

Hi,
Error says AuthenticationEventListener.php but service definition says AuthenticationSuccessListener, classname-filename mismatch.

my mistake.. OMG!.. i was obfuscated xD
Thanks @chalasr


Windows Support

The addition of "/" to all library paths from PLEX if they do not end with a "/" (#102) does not work for PLEX servers running on Windows machines,
This is currently an issue in my setup. I have my "arrs" installed in Docker containers with say "/tv/" as the path. My PLEX server is installed on a Windows machine with the TV folder as "T:\tv".
When Autoscan returns the libraries it is showing TV as having a path of "T:\tv/".
In the triggers I have setup a rewrite of:
from: /tv
to: T:\tv

In the Targets I have:
from: /
to: \

Say a request comes in for /tv/Show/Season 1/Show - s01e01.mkv the triggers will rename it to T:\\tv/Show/Season 1/Show - s01e01.mkv This would work if this was the path used for PLEX but it is not. The path used is the one generated from the targets. which is changed to T:\\tv\\Show\\Season 1\\Show - s01e01.mkv which does not match the section path of T:\\tv/ If I do not change the / for \ then the path is wrong for plex.
a proposed solution would be to add a few extra checks and a ELSE IF.
//Add trailing forwardslash if there is none for Unix file system.
if len(libPath ) > 0 && !strings.Contains(libPath , ":\\\\") && libPath[len(libPath)-1] != '/' {
	libPath += "/"
}

//Add trailing backslash if there is none for Windows file system.
else if len(libPath ) > 0 && strings.Contains(libPath , ":\\\\") && libPath[len(libPath)-1] != '\\\\' {
	libPath += "\\\\"
}

Hi,
Autoscan does not officially support Windows (although WSL2 is supported). This mainly comes from the fact that we could not land on a solid API design for targets and triggers to be either windows- or unix-based (and to then rewrite the paths accordingly).
While your suggestion makes a lot of sense, I think there are other parts of Autoscan which are not Windows-compatible as well. Think of a scenario where triggers are running on UNIX (Docker) while the Plex server is running on Windows (non-Docker). With that in mind, I will not commit your suggested change as I either want to fully support Windows with Autoscan or not at all. Not some 50/50 support.
Until we fully support Windows, I suggest you to fork the project in the meanwhile.

I'd be interested by this as my PMS also is on windows, if you changed your mind :p


Loading option has no cssClass option, yet is documented as having one

https://github.com/driftyco/ionic/blob/2.0/ionic/components/loading/loading.ts#L136

Will be fixed in beta.7


Getting warning about author key being deprecated

With Hugo 0.120.3, I am getting a warning:
> hugo server -D
...
hugo v0.120.3-a4892a07b41b7b3f1f143140ee4ec0a9a5cf3970+extended darwin/arm64 BuildDate=2023-11-01T17:57:00Z VendorInfo=gohugoio

WARN  The author key in site configuration is deprecated. Use params.author.name instead.

Any chance we can update https://1bl4z3r.github.io/hermit-V2/en/posts/explaining-configs/ to match this?
Thanks in advance

Hi @jamesbraza,
I saw this yesterday and concluded to keep that for future me. Now, I'm that future me.
I will push a change shortly

Changes pushed.
Warning should be resolved.
Closing Issue

Haha thanks for knocking this out! Appreciate your fast work 👍 .
Fyi I am hitting a slight follow up issue, which I describe in https://github.com/1bl4z3r/hermit-V2/issues/42


Bug report

The model was set using /Model command
Unexpected error: litellm.NotFoundError: AnthropicException -
b'{"type":"error","error":{"type":"not_found_error","message":"model:  anthropic.claude-3-5-sonnet-20240620-v1:0"}}'
Traceback (most recent call last):
File "C:\Python311\Lib\site-packages\litellm\llms\anthropic\chat.py", line 725, in make_sync_call
response = client.post(
^^^^^^^^^^^^
File "C:\Python311\Lib\site-packages\litellm\llms\custom_httpx\http_handler.py", line 371, in post
raise e
File "C:\Python311\Lib\site-packages\litellm\llms\custom_httpx\http_handler.py", line 357, in post
response.raise_for_status()
File "C:\Python311\Lib\site-packages\httpx_models.py", line 763, in raise_for_status
raise HTTPStatusError(message, request=request, response=self)
httpx.HTTPStatusError: Client error '404 Not Found' for url 'https://api.anthropic.com/v1/messages'
For more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/404
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "C:\Python311\Lib\site-packages\litellm\main.py", line 1586, in completion
response = anthropic_chat_completions.completion(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Python311\Lib\site-packages\litellm\llms\anthropic\chat.py", line 1117, in completion
completion_stream = make_sync_call(
^^^^^^^^^^^^^^^
File "C:\Python311\Lib\site-packages\litellm\llms\anthropic\chat.py", line 729, in make_sync_call
raise AnthropicError(
litellm.llms.anthropic.chat.AnthropicError: b'{"type":"error","error":{"type":"not_found_error","message":"model:
anthropic.claude-3-5-sonnet-20240620-v1:0"}}'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "C:\Python311\Lib\site-packages\aider\coders\base_coder.py", line 1115, in send_message
yield from self.send(messages, functions=self.functions)
File "C:\Python311\Lib\site-packages\aider\coders\base_coder.py", line 1392, in send
hash_object, completion = send_completion(
^^^^^^^^^^^^^^^^
File "C:\Python311\Lib\site-packages\aider\sendchat.py", line 87, in send_completion
res = litellm.completion(**kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Python311\Lib\site-packages\litellm\utils.py", line 1086, in wrapper
raise e
File "C:\Python311\Lib\site-packages\litellm\utils.py", line 974, in wrapper
result = original_function(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Python311\Lib\site-packages\litellm\main.py", line 2847, in completion
raise exception_type(
^^^^^^^^^^^^^^^
File "C:\Python311\Lib\site-packages\litellm\utils.py", line 8194, in exception_type
raise e
File "C:\Python311\Lib\site-packages\litellm\utils.py", line 6656, in exception_type
raise NotFoundError(
litellm.exceptions.NotFoundError: litellm.NotFoundError: AnthropicException -
b'{"type":"error","error":{"type":"not_found_error","message":"model:  anthropic.claude-3-5-sonnet-20240620-v1:0"}}'
Aider version: 0.57.1
Python version: 3.11.4
Platform: Windows-10-10.0.19045-SP0
Python implementation: CPython
Virtual environment: No
OS: Windows 10 (64bit)
Git version: git version 2.45.2.windows.1

Thank you for filing this issue.
The autocomplete for /model is confusing currently, as the whole LiteLLM database gets pulled in and some of those entries do not seem to work. The correct command to switch to Sonnet-3.5 inside aider is
 /model claude-3-5-sonnet-20240620

Please try this command and report if this works you (and avoid anthropic.* model names for now)

I'm going to close this issue for now, but feel free to add a comment here and I will re-open. Or feel free to file a new issue any time.


Object Name Misspelled

Object name misspelled and that could cause errors in the future.

MoviePost.js -> Title not Tittle

Thanks For Mention the Issue in MoviePost.js @mshajid


Ensure colons do not break titles

When titles have colons in them, it breaks the liquid template.
This encapsulates the titles in string literals if the user
wants a title with a colon in it.
Closes #38

@parkr it looks like using YAML#dump breaks support for >2.0 versions of ruby. Would you prefer I put   logic to check the ruby runtime and use my previous method for versions >2.0? Or would you like to break support for >1.9 in the next release?
Thanks again for taking time with my PR.

Apparently in ruby 1.9, the string is interpreted as a non-specific tag.

@parkr since the non-specific tag is still valid YAML, I just updated the spec to only ensure that the title is wrapped in quotes, not check that the syntax is exactly the same.

Or would you like to break support for >1.9 in the next release?

Let's remove support for v1.9. We don't support it in Jekyll and it's EOL'd so I'm fine with this. Would you ensure you get the correct title in the YAML and that it parses properly? Thanks!

@parkr I reverted the tests so they test for the exact string. This breaks tests on >1.9, but is better coverage. I think this is ready to :ship: !

@jekyllbot: merge


Forgot expired password

Is there an easy way of bypassing the redirect to the expired password page and allow the user to user Devise's "forgot password" flow?
I've tried to skip authentication in PasswordsController but no matter what I keep getting redirected to the expired password page.

my bad, all I had to do was to link a session destroy in the password expired show page.


[PRESET] Update Compiler Preset F-ZERO X

I would like to update a compiler preset on decomp.me.

Preset Name: F-ZERO X
Preset ID: 135
Platform: n64

Compiler is currently ido 5.3 but I now believe should be ido 7.1

Changed! Also I noticed the official spelling of  the game has Zero instead of ZERO, so I changed that as well - hope you don't mind

Sounds good to me, thanks!


Docs: Screencast demo of secor on kubernetes

Youtube demo of demostrating secor on kubernetes using GCP , which should make it easier for people to get started with secor with provided helm charts and understanding notes done in README.kubernetes.md

Looks cool, thanks for the promotion.


Update Rust to 1.77.0

Release notes: https://blog.rust-lang.org/2024/03/21/Rust-1.77.0.html
Thanks to #6886 the diff is reasonable, only for one new lint clippy::suspicious_open_options. I added truncate() calls to the places where it is obviously the right choice to me, and added allows everywhere else, leaving it for followups.

there is a cargo install error for cargo-deny, they ask to use the --locked param: https://github.com/EmbarkStudios/cargo-deny/issues/637#issuecomment-2012011517

A bunch of jobs report:
2024-03-21T18:30:40.2935932Z #102 32.99 E: Failed to fetch http://deb.debian.org/debian/pool/main/g/gcc-10/libquadmath0_10.2.1-6_amd64.deb  Connection timed out [IP: <IP_ADDRESS> 80]
2024-03-21T18:30:40.2937165Z #102 32.99 E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

I suppose a transient network issue, will retry.

Due to #6795, an update of the tag should now be automatic, and not require manual update like done in the last update and the ones before.


How to ease usage under k8s

The default path for secrets (/run/secrets) is used internally by k8s so we can't just mount our secrets there (https://github.com/kubernetes/kubernetes/issues/65835).
What we can do about it:

hardcode dir param in Secret - now our app stops working in docker (e.g. for testing)
mount each secret separately in k8s - manual updates, error prone
make the secrets dir configurable - we're back to using os.environ

@dataclass
class Settings:
  secret: Annotated[str, Secret('secret', os.environ('secrets'))]

Any other solutions?

I think I probably imagined someone subclassing to customize the directory. Although in your case, it seems like you're either looking for a toggle or a fallback.
I think if you wanted a solution integrated into the library, fallback would probably be the thing here. Perhaps something like:
MySecret = Secret.configure(dir=('some-k8s-location', '/run/secret'))
# or manually supplying the dir to every instance)

@dataclass
class Settings:
  secret: Annotated[str, MySecret('secret')]

Alternatively I could imagine adding a central configuration option like an aws-secret might have so it'd be more like
@dataclass
class Settings:
  secret: Annotated[str, MySecret('secret')]

load_settings(Settings, loader_args=Secret.load_as('/run/secret'))  # where this could be set by env var

probably I like option 2 better, although they're not actually mutually exclusive either.

we're back to using os.environ

I'm not sure what exactly you meant by that. but i could take that as you having issue with option 2, because it would imply an env-var lookup to figure out the dir. But that would seem to be required of any solution that doesn't involve a fallback, that I can think of.
Thoughts on my thoughts?

Curious what you think of this. Some of this you likely dont need/wont use, but it all seemed to logically flow together depending on what are probably personal preferences.

The dir can be a string or a sequence of strings. This will seek those locations in order.

Secret(dir=('/run/secrets', '/other/place')

One can pre-configure a Secret statically

MySecret.with_dir(dir=('/run/secrets', '/other/place'))

class Foo:
    bar: Annotated[str, MySecret()]

The paths can be supplied at load-time. This enables you to avoid making the path decision at import time, and defer it to wherever you're performing loading.

class Foo:
    bar: Annotated[str, MySecret()]

def main():
    settings = load_settings(
        Foo,
        loader_args=Secret.load_as(dir=os.environ.get('SECRET_ROOT', '/run/secret'))
    )

I'm not sure that I see a ton of value in this library making the (fairly opinionated) decision of where to retrieve the concrete root dir value from (as far as your suggestion to optionally load it from an environment variable goes).

Curious what you think of this. Some of this you likely dont need/wont use, but it all seemed to logically flow together depending on what are probably personal preferences.
1. The dir can be a string or a sequence of strings. This will seek those locations in order.

Secret(dir=('/run/secrets', '/other/place'))

Works for simple cases but get repetitive really quick. Also suggests that you might want to load secrets from different directories (which you don't, right? ;)
class MyConfig:
  foo: Annotated[str, Secret(dir='path1')]
  bar: Annotated[str, Secret(dir='path2')]

2. One can pre-configure a Secret statically

MySecret = Secret.with_dir(dir=('/run/secrets', '/other/place'))

class Foo:
    bar: Annotated[str, MySecret()]

Not a big fan of this style.
MySecret = Secret.with_dir(...)

it tries to look like a subclass. But that's purely personal preference, otherwise it's short and clear.

3. The paths can be supplied at load-time. This enables you to avoid making the path decision at import time, and defer it to wherever you're performing loading.

class Foo:
    bar: Annotated[str, MySecret()]

def main():
    settings = load_settings(
        Foo,
        loader_args=Secret.load_as(dir=os.environ.get('SECRET_ROOT', '/run/secret'))
    )

I don't think I ever seen a design like loader_args...  I think you intended to make it extensible but I'm not sure how it's supposed to work. What structure Secret.load_as would return? dict? tuple? How to mix it with args for other loaders? Are there any?
Other options:

separate loaders from annotations and pass loaders explicitly

load_settings(
  MyConfig,
  loaders=(EnvLoader, SecretLoader('path'))
)

use **kwargs

load_settings(MyConfig, secret_roots=(path1, path2))

pass all **kwargs to all loaders and let them sort it out.

4. I'm not sure that I see a ton of value in this library making the (fairly opinionated) decision of where to retrieve the concrete root dir value from (as far as your suggestion to optionally load it from an environment variable goes). It seems like roughly the same amount of user-written code, but with objectively more flexibility on your end on where to retrieve that value from.

Or just say it's only for apps running in docker ;)
Anyway, I prefer it to pydantic-settings

Works for simple cases but get repetitive really quick. Also suggests that you might want to load secrets from different directories (which you don't, right? ;)

I mean ultimately, that's the goal is it not? Either you must load from two different paths in sequence (1/2), or you need to load the configuration of where to load the configuration from before you call load_settings (3).

I don't think I ever seen a design like loader_args... I think you intended to make it extensible but I'm not sure how it's supposed to work. What structure Secret.load_as would return? dict? tuple? How to mix it with args for other loaders? Are there any?

At present loader_args is just dealing in dicts, which would not be composable. The moment there is more than one loader with necessary pre-config, i'd likely create some LoaderArgs object which one can use directly, or where Secret.load_as(...) | AWSSecretStore.load_as() would be shorthand for explicitly enumerating them.

loaders=(EnvLoader, SecretLoader('path'))

This is essentially the same thing, but where you need to both externally (as in the user needs to realize this and import 2 different objects) and internally (for the code to function) relate Secret and SecretLoader.
I guess I will say, there's already a loaders= (and extra_loaders=) argument which could probably be made to work similarly to my solution. as in extra_loaders=(Secret.load_as('path'),). And where today's extra_loaders=(Secret,) would be shorthand for Secret.load_as(), e.g. the default. And that is ultimately similar to what you suggested, except that I probably wont expose a separate Loader class from a user's perspective at least.
I'd be open to revising to this strat and removing loader_args, since it's as-yet unused by any loaders.

pass all **kwargs to all loaders and let them sort it out.

😬 definitely not doing that

Or just say it's only for apps running in docker ;)

Not sure what you mean by this. the paragraph you quoted for that was just that I think it's unnecessary opinionated-ly choosing to bake env-loading in to every loader. You can arrive at the same behavior (while staying flexible to other options) more clearly and just as concisely in user code.

Works for simple cases but get repetitive really quick. Also suggests that you might want to load secrets from different directories (which you don't, right? ;)

I mean ultimately, that's the goal is it not? Either you must load from two different paths in sequence (1/2), or you need to load the configuration of where to load the configuration from before you call load_settings (3).

Perhaps I didn't phrase it well, but the example explained it. I meant it looks like you're going to load each secret from a different directory.
And actually I don't even like passing a list of directories for fallback.
this form will attempt loading from only one directory:
secret_root = os.environ.get('SECRETS_ROOT', '/my/default')

secret_root = ['/etc/secrets','/my/fallback']

With the second form I can imagine a really bad scenario where a name clash leads to some secrets loaded from one directory and other secrets from another, making a hard to track problem in deployment, potentially even a security issue. I'm not saying you can't have it in the library, I'm just not going to use it.

I guess I will say, there's already a loaders= (and extra_loaders=) argument which could probably be made to work similarly to my solution. as in extra_loaders=(Secret.load_as('path'),). And where today's extra_loaders=(Secret,) would be shorthand for Secret.load_as(), e.g. the default. And that is ultimately similar to what you suggested, except that I probably wont expose a separate Loader class from a user's perspective at least.
I'd be open to revising to this strat and removing loader_args, since it's as-yet unused by any loaders.

Works for me. I think loader_args is a roundabout very way of configuring loaders, when you could simply pass loaders directly, either explicitly or via some form of factories.
You can add a LoaderFactory(Protol) and let Secret and others implement it, change loaders and extra loaders in  load_settings accept Sequence[Loader|LoaderFactory], this way users can pass Secret or Secret.load_from(dir) as either loaders or extra_loaders.
Why load_as and not load_from? load_as suggest a target, a name for the secret, but we're passing source.

pass all **kwargs to all loaders and let them sort it out.

😬 definitely not doing that

Not a big fan either, but I've seen it done and it works for simple cases.

Or just say it's only for apps running in docker ;)

Not sure what you mean by this. the paragraph you quoted for that was just that I think it's unnecessary opinionated-ly choosing to bake env-loading in to every loader. You can arrive at the same behavior (while staying flexible to other options) more clearly and just as concisely in user code.

I guess I misread you and made a bad attempt to make a joke.

I'm not saying you can't have it in the library, I'm just not going to use it.

As much i figured, it just seemed liked a natural extension, given the rest of the lib and the other changes. I expected my original option 3 to be at the least the preferable strategy here.

Why load_as and not load_from?

load_from makes sense to me for e.g. Secret. Something like, say, AWSSecretStore where you might need other aws-specific secrets to initialize the boto3 client or whatever felt like it'd make less sense. Although my initial reaction to load_from was definitely that it seemed better. I'll have a think on the naming.

How about this
class SecretLoader(Loader):
  ...
class LoaderFactory(Protocol):
  def load()->Loader:
    pass
class Secret(LoaderFactory):
  ...
  def load():
    return SecretLoader() # with any defaults
  def load_from(dir: str|Sequence[str]|Path|Sequence[Path]):
    return SecretLoader(dir)

class AWSSecret:
  def load():
    # create using  env (e.g AWS_PROFILE)
  def load_with(creds...):
   ...

def load_settings(model_type, loaders: Sequence[Loader|LoaderFactory]):...

load_settings(ConfigModel, loaders=(Env, Settings.load_from(dir)))

This way user can pass Secret for the default behaviour or use a factory method, which can be named accordingly, and Loader hierarchy doesn't need to be exposed


Major refactoring of core systems, and new patch selection UI components. Work in progress!

Major refactoring of core systems, and new patch selection UI components.
Work in progress!

Please check my latest changes and feedback here: https://github.com/Ravo92/Patch-2.22-Launcher/pull/46/commits/ef43b2fae825ffdc7a4a8edc6a72961691fec353

Forgot some parts...
https://github.com/Ravo92/Patch-2.22-Launcher/pull/46/commits/6e137c3b6d0b12785be5c228a26d2c3764264c6e

I took a quick look, and all seems fine, using enums instead of integers to specify the game is a good idea.
But, I have a problem with the naming convention you are using, it's inconsistent. Here are my suggestions:

The AvailableBFMEGames enum should be named BfmeGame
The availableBFMEGames parameter in functions should be renamed to game in all functions that use it
BFMELaunchManager, BFMERegistryManager, BFMESettingsManager and all classes that use the BFME<Something> naming convention should be renamed Bfme<Something>, so BfmeLaunchManager, BfmeRegistryManager, etc...
Settings_BFME1General, Settings_BFME1Repair and all settings pages that use the Settings_<BFMEGAME><Something> naming convention should be renamed Settings_<Bfmegame><Something>, so Settings_Bfme1General, Settings_Bfme1Repair, etc...

The reason behind this is to maintain naming consistency across the project, since all other static classes follow the "UpperCamelCase" naming convention (eg.: SystemDisplayManager, SystemInputManager, LauncherStateManager, LauncherUpdateManager, etc...)

Looks good!


added support for no username/password

hi @alexazarh, pushed another commit with the requested changes.
please note, an additional change was made to the shell itself, added the "convert_to_bool" function as the Shell was calling the "EmailConfig" directly (bypassing the "create_from_config_resource" that was in use in the setup/teardown scripts)


Add FLT prefix to all ObjC types declared by plugins.

Fixes https://github.com/flutter/flutter/issues/10073

This now results in the following error. Any suggestions
 ../ios/Runner/GeneratedPluginRegistrant.m:20:4: error: unknown receiver 'PathProviderPlugin'; did you mean 'FLTPathProviderPlugin'?
      [PathProviderPlugin registerWithRegistrar:[registry registrarForPlugin:@"PathProviderPlugin"]];

Which version of Flutter are you using? It would only work with newest alpha or master updated within the last couple of weeks (since https://github.com/flutter/flutter/commit/4676e1d724c76d1cd5a84cef35514472e3641018)

That is correct. Flutter upgrade solved the problem.


FrontSmartCoupon

Does this occur consistently?
Repro steps:

Action: staticWebApps.createStaticWebApp
Error type: Error
Error Message: User did not consent to login.
Version: 0.4.0
OS: win32
OS Release: 10.0.16299
Product: Visual Studio Code
Product Version: 1.49.2
Language: en

Call Stack
t.ExtHostAuthentication.getSession extensionHostProcess.js:670:641
processTicksAndRejections task_queues.js:94:5

Hi @rbaroudi
It seems like you need to give VS Code permission to use your Github account.  Let me know if you need any help doing that.

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


Support binary transfers

This module is sweet! I cant believe it does all of that in so few lines of code
@feross and I just tried streaming a one-hour-long mp3 using webcat.
The first issue we ran into is that webcat doesn't support binary data. Maybe it's interpreting the input as ascii or UTF8? Either way, I had to pipe thru base64 before sending it thru webcat.
With that workaround, it works for a few minutes before it dies. I think what's going on is that there isn't any backpressure, so the receiving webcat process buffers a lot of data. Once the whole (~150MB) file is sent, the sending webcat process closes the connection & exits. The receiving process sees the connection died and exits as well, even though it still has lots of data that needs to be flushed to stdout.
With the following fixes, I think it would work

[ ] Flush stdout before exiting (most important)
[ ] Handle binary input
[ ] Implement back pressure

What @dcposch said :+1:


Webjobs console doesn't support colorization

Webjobs console apparently doesnt support colorization, ie, running a Powershell ps1,
write-host -foreground-color green "Starting job..."

fails.
Powershell host environment should either A) support colorization, B) just output without colors
Expected output:
Starting job
Actual output:
"Error, something about feature not available" and no output...

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

ID: 24523dbf-010f-b844-5ff0-88192eac8849
Version Independent ID: d7ef5962-d94c-96d0-bf08-1efffc6d402b
Content: Run Background tasks with WebJobs - Azure App Service
Content Source: articles/app-service/webjobs-create.md
Service: app-service
GitHub Login: @ggailey777
Microsoft Alias: glenga;msangapu;david.ebbo;suwatch;pbatum;naren.soni;

@ericnewton76 We value your feedback but as mentioned in your other issue, we scope GitHub to Doc Feedback. Please share your product feedback directly with the product group at Azure UserVoice.
Thank you for your understanding.


If the first thing in the text is an icon, it is rendered very small.

This happens for all icons that are added before any text, including spaces.

input:
 A
Expected:
Renders "[ICON][ICON] A [ICON]" and all icons are the same size.
Actual:
Renders "[ICON][ICON] A [ICON]" and first two are very small.

This happens for all icons that come before any string content.

fixed in 2.0.3


odo.dev: reorder getting-started section

What type of PR is this:
/kind documentation
What does this PR do / why we need it:
Installation should be listed before quickstart

Makes sense! I agree with the new order
/lgtm
/approve


The ! character is not being escaped

I have a swap called ${conversionMessage}. The contents are: usersession.stringProperties.bookingmessage23="Your journey was booked successfully! Open the summary and print out the ticket's."
The result is:
usersession.stringProperties.bookingmessage23%3D%22Your%20journey%20was%20booked%20successfully!%20Open%20the%20summary%20and%20print%20out%20the%20ticket's.
It should be:
usersession.stringProperties.bookingmessage23%3D%22Your%20journey%20was%20booked%20successfully%21%20Open%20the%20summary%20and%20print%20out%20the%20ticket's.

Issue was actually with Powerups, not Configurator. Changed regex in argsplit to allow for ! in URL parameters.


Fix tag specifications crash for EC2 resources

It seems like moto mishandles tags for a some EC2 resources with the error AttributeError: 'list' object has no attribute 'get'.
Commands to reproduce:
awslocal ec2 create-vpc --cidr-block <IP_ADDRESS>/16
awslocal ec2 create-subnet --vpc-id "$VPC_ID" --cidr-block <IP_ADDRESS>/20 --tag-specifications '{"Tags":[{"Key":"Name","Value":"ok"},{"Key":"Hello","Value":"World"}]}'

I could replicate this error for VPC, Subnets, and Route Tables and just fixed the other EC2 resources which had the same faulty pattern.

@bblommers Fixed linting

This last failing job, is it a random fail? It doesn't look related to the changes.

Hi @RaJiska!
From the docs:

The tags to apply to a resource when the resource is being created. When you specify a tag, you must specify the resource type to tag, otherwise the request will fail.

When you do specify ResourceType=subnet, it works as expected.

AWS throws this error:

An error occurred (InvalidParameter) when calling the CreateSubnet operation: Tag specification resource type must have a value

Validation is now part of Moto thanks to https://github.com/getmoto/moto/pull/6860, so I'll close this.


Fix expanded state announce for dialog headers

Fixes https://github.com/microsoft/azuredatastudio/issues/15728
This is a really odd one. I feel like this is a bug with NVDA, Angular or some combination of the two - if I make it so clicking the button doesn't change the container display then it announces just fine. So something with setting the display on the container is messing with the announce. But nesting it in an empty div fixes it for some reason...
(Narrator is even worse - it doesn't even announce the expanded state when it changes in any scenario, just when you tab over it initially. But it announces it correctly for actual buttons, so maybe some issue with it and the button role?)
I can't seem to repro this outside of ADS so don't really have much to give to the NVDA folks - I'll see if there's any issues that seem similar though to at least try to understand why this is broken.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 42.47%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
26784

Relevant Lines:
57118

💛  - Coveralls


add cmake support

almost required for #89
similarly, would make things much easier for #86

c1ed35c02b7e62945fcefab85de1c8325811d46a


[rt.openssl.org #3936] Bug (maybe) report

Migrated from rt.openssl.org#3936 (status was 'open')
Requestors:

<EMAIL_ADDRESS>
From<EMAIL_ADDRESS>on 2015-07-10 21:02:24:
This could be a real bug, a doc bug, or I'm just not getting it.

I'm using "-config" with "openssl req" and "openssl ca" to use an alternate openssl.cnf file.  The command bombs because (being run as non-root) it can't read the default /etc/pki/tls/openssl.cnf file, since it is owned by root and mode 600 (CentOS 6.2, openssl 1.0.1e from RPM), and the command is not being run as root.

My alternate openssl.cnf file is in the current working directory, and I have tried making the -config argument each of "openssl.cnf", "./openssl.cnf", and the full absolute path to the file.  My file is mode 600 and owned by the user running the command and has mode 600.

In no case does it complain of not being able to read my file (but maybe it never gets that far).  It complains of not being able to read the default file.

So, does -config *NOT* suppress reading of the default file (the man page implies that it does)?  Have I missed an option for suppressing it?

Is this a bug, a local installation problem, or could the documentation use improvement.

Here's an example of a failing command:

(imposter)[ imposter@imposter_bill ~/imposter/non-git/CA ]
$ openssl req -config /home/imposter/imposter/non-git/CA/openssl.cnf  -newkey rsa -nodes -keyout localhost.key -out localhost.csr
140615126005576:error:0200100D:system library:fopen:Permission denied:bss_file.c:169:fopen('/etc/pki/tls/openssl.cnf','rb')
140615126005576:error:2006D002:BIO routines:BIO_new_file:system lib:bss_file.c:174:
140615126005576:error:0E078002:configuration file routines:DEF_LOAD:system lib:conf_def.c:199:
(imposter)[ imposter@imposter_bill ~/imposter/non-git/CA ]
$

From unknown on 2015-09-09 20:49:34:
OpenSSL attempts to load the master/default conf before diving into the
subcommand and overriding the conf with the config in -config. It'll bail when
it can't read the file, but only warn if the file does not exist.

This seems wrong, and is a regression compared to 0.9.8, so I'm going to leave
this ticket open.

Meanwhile, you can work around it by setting the OPENSSL_CONF environment
variable.

Cheers,
Emilia

From a look in master, it seems that we try to load module settings from the default config file regardless, and any file error is treated silently.  However, if the file was successfully loaded, but the configuration is somehow wrong (i.e. CONF_modules_load fails), then openssl will bail.
I'll do a quick test to see if I'm right.

I've just tried the example command on current master, 1.1.0 and 1.0.2 branches.  Cannot reproduce.
Closing this