LiFi trades failing, seemingly after new approvals

Overview
Currently in production when a user attempts a trade requiring a new approval of a token trade through LiFi, the trade after the approval action errors and the user gets a 'Something went wrong' error message.
References and additional details
USDC.BNB>BNB.BNB on native wallet:
https://github.com/shapeshift/web/assets/94998097/eac3b80f-9c5c-412b-8290-f3c749d08ffc
USDC.OP>USDT.OP on native wallet:
https://github.com/shapeshift/web/assets/94998097/8acb9368-151c-493e-85c8-8e8f13882a0d
Error from network tab: https://api.optimism.shapeshift.com/api/v1/gas/estimate?data=0x4630a0d8b2d3bf74627583b8a3bc308e8e66cec1e4519816befc8668b8b314daac654b7300000000000000000000000000000000000000000000000000000000000000c000000000000000000000000000000000000000000000000000000000000001000000000000000000000000009a56d3d1a6631376cc0c5dc45a1453ea0287a9380000000000000000000000000000000000000000000000000000000002f51bf30000000000000000000000000000000000000000000000000000000000000160000000000000000000000000000000000000000000000000000000000000000a7368617065736869667400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002a307830303030303030303030303030303030303030303030303030303030303030303030303030303030000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000001e0000000000000000000000000bd6c7b0d2f68c2b7805d88388319cfb6ecb50ea9000000000000000000000000bd6c7b0d2f68c2b7805d88388319cfb6ecb50ea90000000000000000000000000b2c639c533813f4aa9d7837caf62653d097ff850000000000000000000000000b2c639c533813f4aa9d7837caf62653d097ff850000000000000000000000000000000000000000000000000000000002f8b7ef00000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000084eedd56e10000000000000000000000000b2c639c533813f4aa9d7837caf62653d097ff850000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000090a48d5cf7343b08da12e067680b4c6dbfe551be00000000000000000000000000000000000000000000000000000000000000000000000000000000ca423977156bb05b13a2ba3b76bc5419e2fe9680000000000000000000000000ca423977156bb05b13a2ba3b76bc5419e2fe96800000000000000000000000000b2c639c533813f4aa9d7837caf62653d097ff8500000000000000000000000094b008aa00579c1307b0ef2c499ad98a8ce58e580000000000000000000000000000000000000000000000000000000002f8b7ef00000000000000000000000000000000000000000000000000000000000000e0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000bc83bd37f900010b2c639c533813f4aa9d7837caf62653d097ff8500070402f8b7ef0402f8e9eb0147ae0001926faafce6148884cd5cf98cd1878f865e8911bf000000011231deb6f5749ef6ce6943a275a1d3e7486f4eae59725ade03010204001f0101010203ff00000000000000000000000000000000000000000050a39b94b1dc8472faa08c36a3ef5b0a01c5bd100b2c639c533813f4aa9d7837caf62653d097ff8594b008aa00579c1307b0ef2c499ad98a8ce58e580000000000000000&from=0x9a56D3d1A6631376cC0c5DC45A1453eA0287a938&to=0x1231DEB6f5749EF6cE6943a275A1D3E7486F4EaE&value=0
USDT.OP>USDC.OP on KeepKey:
https://github.com/shapeshift/web/assets/94998097/c00962a5-064a-4b9f-927a-21555bee50d2
Acceptance Criteria
Users are able to perform LiFi trades successfully regardless of wallet or asset pair.
Need By Date
No response
Screenshots/Mockups
No response
Estimated effort
No response

This also may be intermittent/non-deterministic as @MBMaria and I have both had transactions fail where we don'r need approvals either.

This was also confirmed in Prod (videos say release) to assure it was not a release blocker. More recreations can be uploaded if requested.

This is actually unrelated to approvals and affects ERC20 trades due to an error estimating gas. Trades from native assets seem unaffected.
Looks to be unrelated to any changes on our side. I've contacted lifi for assistance:
https://discord.com/channels/554694662431178782/1080826012784414720/1220228291235938336


[fix][schema] Only handle exception when there has

Fixes #xyz

Main Issue: #xyz

PIP: #xyz

Motivation
When seeing the warning log, there should have a reason why it shows. But the cause is empty, and the logic is running correctly. We should only print them when the exception is not null.
Modifications

Verifying this change

[ ] Make sure that the change passes the CI checks.

(Please pick either of the following options)
This change is a trivial rework / code cleanup without any test coverage.
(or)
This change is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end deployment with large payloads (10MB)
Extended integration test for recovery after broker failure

Does this pull request potentially affect one of the following parts:

If the box was checked, please highlight the changes

[ ] Dependencies (add or upgrade a dependency)
[ ] The public API
[x] The schema
[ ] The default values of configurations
[ ] The threading model
[ ] The binary protocol
[ ] The REST endpoints
[ ] The admin CLI options
[ ] The metrics
[ ] Anything that affects deployment

Documentation

[ ] doc
[ ] doc-required
[x] doc-not-needed
[ ] doc-complete

Matching PR in forked repository
PR in forked repository:

Codecov Report

Merging #20730 (6d8b61a) into master (ac33311) will increase coverage by 0.15%.
The diff coverage is 57.14%.

@@             Coverage Diff              @@
##             master   #20730      +/-   ##
============================================
+ Coverage     73.00%   73.15%   +0.15%
+ Complexity    32096     3737   -28359
============================================
  Files          1868     1868
  Lines        138999   139000       +1
  Branches      15292    15292
============================================
+ Hits         101479   101691     +212
+ Misses        29485    29257     -228
- Partials       8035     8052      +17

Flag
Coverage Δ

inttests
24.19% <0.00%> (?)

systests
25.03% <0.00%> (-0.07%)
:arrow_down:

unittests
72.43% <57.14%> (+0.04%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...broker/service/schema/BookkeeperSchemaStorage.java
79.39% <57.14%> (+0.67%)
:arrow_up:

... and 78 files with indirect coverage changes


Reject fix

This pull request also adds simple node status logging and a fix to the nodes network height tracking.

ACK

I've added height indices in the header tree so that we can build block locators quickly without having to scan the entire chain. I've also removed some redundant information that was being kept around in memory while downloaded merkles blocks.


replace rand with ark_std::rand and drop rand_xorshift

Description
This PR lets r1cs_std directly uses ark_std::rand. Also, this PR replaces the use of XorShiftRng with the standard test_rng.
closes: #30 , #31

[x] Targeted PR against correct branch (main)
[x] Linked to Github issue with discussion and accepted design OR have an explanation in the PR that describes this work.
[x] Wrote unit tests
[x] Updated relevant documentation in the code
[ ] Added a relevant changelog entry to the Pending section in CHANGELOG.md
[ ] Re-reviewed Files changed in the Github PR explorer

Feel that no changelog entry is needed for this PR since it does not belong to any of the categories...


Memory exhausted running phantom on Windows

I am running phantom on Windows and after 10 minutes the program crashes on memory exhausted, even though the used physical memory reached only 25%, Is there any feature in the OS to limit the cmd memory usage? is it a bug?

Bump

Bump

@ariya Can you please help?

Do you have loadImages set to false? See https://github.com/ariya/phantomjs/issues/12903

Yes I do, also the plugins

A fix is in the works. https://github.com/Vitallium/qtwebkit/pull/8

OK, so if I set it to true then there shouldn't be a leak on Windows?

Assuming it's the same bug, there shouldn't be a leak. There's also a work-around discussed in #12903.

thx @mepard
LoadImage was set to false too.
I will switch it to on.

I hit a situation that caused Memory Exhausted even with LoadImages set to false and posted my solution in #11390.
This bug should probably be closed in favor of #11390.


Selection can show over empty space in Local Scope section of Component Browser.

This task is automatically imported from the old Task Issue Board and it was originally created by Mateusz Czapliński.
Original issue is here.

Steps to reproduce
To reproduce:

Hover the mouse over an item in the left column of the Local Scope section.
Type letters "ab" on the keyboard.

Expected
The selection should show highlight some existing entry in the Component Browser.
Actual
The selection shows over a space that does not contain any entry of the Component Browser.

Check if it is still valid

Closing because the updated design of the Component Browser does not have the Local Scope section anymore


cannot create splitfq folder

If an output directory is specified in config.yaml,
https://github.com/GuttmanLab/chipdip-pipeline/blob/73a2539718e12f1d11cf20c41a99cb032f62348a/config.yaml#L12C1-L12C15
in the splitfq rule, a <output_directory>/workup folder is not created. In fact, even if a workup folder already exists in the output directory, it will get deleted. However, if no output directory is specified, a workup folder will be created in the working directory by default and everything runs fine. The issue probably resides here:
https://github.com/GuttmanLab/chipdip-pipeline/blob/73a2539718e12f1d11cf20c41a99cb032f62348a/Snakefile#L97-L102

Could not reproduce bug.

Was finally able to reproduce bug, hence reopening this issue.
Steps to reproduce issue:

Delete any workup/ directory in the working directory
Edit config.yaml to use a different output_dir than ""
Run the pipeline on a SLURM cluster (./run_pipeline.sh)
The pipeline will stall after initial jobs (whether split_fastq or log_config), leaving the pipeline in the following state:

No pipeline-related SLURM jobs running: squeue -u <username> will show no running jobs from the pipeline
./run_pipeline.sh script does not crash or show any sign of error - it is still "running" but is actually stalled
(Not sure if happens every time) No split_fastq folder is created under <output_dir>/workup
(Not sure if happens every time) Although <output_dir>/workup/logs is created, no actual log files are recorded there.

The problem appears to be due to paths for SLURM output and error files specified in cluster.yaml. These paths <working directory>/workup/cluster/... are relative to the working directory and are not updated when the user changes the desired output directory in config.yaml. Consequently, the SLURM job fails when it tries to write these SLURM output and error files to a <working directory>/workup/cluster/ directory that does not exist.


Return BOTH where we would normally return NAMESPACED

This resolves the navigation behavior described in #4428 by returning BOTH where we would normally return NAMESPACED. I don't necessarily think that this is the optimal approach, but it does look to be the most straightforward for right now. To better understand why I'm proposing this change, here's a quick rundown of the issue as I see it:

We make a decision on which menu items should be displayed based on multiple factors, the two most relevant ones for this issue are Product ID and Namespace
Product ID is able to override namespace when defining top-level menu structure, causing items like Cluster to conditionally render based on route (Apps & Marketplace shows Cluster while Workload does not)
Navigating to Workload after setting a namespace filter while Apps & Marketplace is active causes the following to take place

Selected Product is updated
default.vue has a watch on productId that triggers a rebuild of the menus, which removes Cluster from the list
Later, groupSelected() is invoked; this attempts to navigate based on the selected index. Since index 1 is no longer Workload we navigate to Apps & Marketplace instead (Workload = 0, Apps & Marketplace = 1)

Making this change to show BOTH prevents us from mutating our menu structure by displaying our menu options as they are regardless of namespace filters or selected product.
I think this change is relatively safe to make because the namespaceModule getter is only used by our default layout for displaying the menu.
#4428

@vincent99 thanks, that seems to do the trick.
We also had to move away from using an index as a key for our groups so that our active menu item remains open after filtering. I opted to used name because it looked to be unique in regards to our menus.


Fix distance tax regression

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/43241
$ https://github.com/Expensify/App/issues/43174
$ https://github.com/Expensify/App/issues/43202
$ https://github.com/Expensify/App/issues/43242
PROPOSAL:
Tests

Go to Settings -> Workspace -> choose a Workspace with enable Taxes
Click Distance Rates -> Click Settings
Verify that: 'Track tax' item is located on the same level as the others
Enable 'Track Tax'
Go to offline mode
Try to update 2 new rows 'Tax Rate' and 'Tax reclaimable on'
Verify that: "Tax rate" and "Tax reclaimable on" will gray out when edited offline.
Go to Taxes.
Delete a tax.
Go to Distance rates.
Choose any rate.
Go to Tax rate.
Verify that: the deleted tax rate should be crossed out
On Mobile: with device font size is minimum (or smaller than the standard size)
Verify that: "Track tax" message will scale according to device font size

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

Offline tests

QA Steps

Go to Settings -> Workspace -> choose a Workspace with enable Taxes
Click Distance Rates -> Click Settings
Verify that: 'Track tax' item is located on the same level as the others
Enable 'Track Tax'
Go to offline mode
Try to update 2 new rows 'Tax Rate' and 'Tax reclaimable on'
Verify that: "Tax rate" and "Tax reclaimable on" will gray out when edited offline.
Go to Taxes.
Delete a tax.
Go to Distance rates.
Choose any rate.
Go to Tax rate.
Verify that: the deleted tax rate should be crossed out
On Mobile: with device font size is minimum (or smaller than the standard size)
Verify that: "Track tax" message will scale according to device font size

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

PR Author Checklist

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

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

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

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

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

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

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

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

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

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

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

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

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

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

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

Screenshots/Videos

Android: Native

https://github.com/Expensify/App/assets/161821005/bf542041-8e27-4815-b7af-d23ea4ac2fa4

Android: mWeb Chrome

https://github.com/Expensify/App/assets/161821005/3860480e-f083-4253-9871-c4a4d7eb4434

iOS: Native

https://github.com/Expensify/App/assets/161821005/581648ed-f708-4718-9cb4-6b9dd3c3373e

iOS: mWeb Safari

https://github.com/Expensify/App/assets/161821005/24c9e2b5-80c5-461a-9b55-c7d0e54d8c55

MacOS: Chrome / Safari

https://github.com/Expensify/App/assets/161821005/9f4a6251-5c28-4b93-a011-505d6ec6685e

MacOS: Desktop

https://github.com/Expensify/App/assets/161821005/7be71519-59ea-4ff2-82c7-77b95e42c813

Thanks @nkdengineer ! Could you also please include this issue https://github.com/Expensify/App/issues/43242

@MonilBhavsar  @eVoloshchak we have this PR to fix regression from 42141

@nkdengineer appreciate this! Could you please update tests and QA section

Looks good overall!

Lint failure here. Can we jump on that now? Thanks!

@trjExpensify @MonilBhavsar @eVoloshchak i updated, please check again 🙏

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

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

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

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

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

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

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

[ ] I verified that all the inputs inside a form are aligned with each other.
[ ] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

BUG
Setting the same value when offline still shows the item as greyed.
https://github.com/Expensify/App/assets/30054992/93c207fa-4925-4913-9a9e-01bd5f702cc0

@nkdengineer are you going to be able to jump on that fix now?

@allroundexperts thanks! Let's continue the review, but not block on it since that's a minor issue compared to the crash. @nkdengineer can you please address that one in this PR?

Cool, I removed https://github.com/Expensify/App/issues/43174 from the list of solved issues since that's still happening. @nkdengineer please address that in a follow up

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to production by https://github.com/luacmartins in version: 1.4.81-11 🚀

platform
result

🤖 android 🤖
failure ❌

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Implement standardized formatting. Closes #4

This PR implements;

Recommended eslint configurations.
A minimalistic prettier setup for code formatting.
An addition to .gitignore to support jetbrains editors.

For readabiliy this PR does not:

Run of "prettier --write ." on the project.
Enforce formatting in the pre-commit hook.
This can be a seperate PR.

@nzakas @jesusprubio My suggestion on modernising the formatting in regards to issue #4 . Can you give feedback and/or merge? 😺

I've already updated the repo to format with ESLint on precommit. Is there any benefit to adding Prettier on top of what's already on main?

As far as i can see, it runs eslint --fix on pre-commit. And the config is not setup to provide very strict formatting. The minimal prettier config provided here should allow for better separation the formatting, while still enforcing a more similar layout between pull requests. It will also become two different commands, one to be run locally and one to act as enforceable Github actions (the linting).
I can remove prettier from the PR, but i think it will make the contribution process a lot more neat in the long run.

I don’t see adding Prettier as providing much additional value at this point. ESLint can enforce the most important parts on precommit. I’d rather stick with one tool right now.

@nzakas i included the correct lint-staged and suggested changes. I also fixed all the problems arising from using eslint:recommended config (code cleanup) and re-wrote from commonjs to modules, to get the most pleasing and maintainable code quality. It should be very good for the future pull requests, so i suggest we merge this one in first.

@MarkKragerup it’s considered a best practice to keep each pull request narrowly focused on just one change. By bundling all of these changes together, it makes the decision all-or-nothing.
This pull request should just be about adding Prettier. If you’d like to propose switching to ESM, please open a separate issue or pull request.

@nzakas 100% agree on the best practise. This PR was adding prettier and the recommended eslint config. When I changed the commands it didnt allow for linting problems. Many problems had to do with require. I bet it was due to a wrong config ln my part, but I eagerly changed to ESM. If you want, I will rewrite it again - but ESM is preferable in my eyes, and more typescript ready, should the occasion arise.

I’d say just start with the changes related to prettier and we can discuss ESM elsewhere.

To save time, I updated this myself.


⚠ Bofrost.be has degraded performance

In e64eb44, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1564 ms

Resolved: Bofrost.be performance has improved in c5419b9.


TLCC channel meta-data parsing is broken

We currently get tons of  errors in tlccs of the form
... tlcc_enclave/enclave/crypto.cpp:102) [Enclave] Crypto: Invalid certificate: unable to get local issuer certificate
... tlcc_enclave/enclave/ledger.cpp:215) [Enclave] Ledger: Envelope signature validation failed

The root cause seems to be that we are not parsing properly anymore the channel config infos anymore ...
tlcc_enclave/enclave/ledger.cpp:74) [Enclave] Ledger: Block number: 0
tlcc_enclave/enclave/ledger.cpp:165) [Enclave] Ledger: Process Envelope[1/1]
tlcc_enclave/enclave/ledger.cpp:187) [Enclave] Ledger: 	\-> Verify envelope signature
tlcc_enclave/enclave/ledger.cpp:198) [Enclave] Ledger: 		\-> MSPID: SampleOrg
tlcc_enclave/enclave/ledger.cpp:224) [Enclave] Ledger: Skip signature validation; genesis block
tlcc_enclave/enclave/ledger.cpp:310) [Enclave] Ledger: ### Parse Config ###
tlcc_enclave/enclave/ledger.cpp:315) [Enclave] Ledger: ConfigEnv.config.ChannelGroup.Groups:
tlcc_enclave/enclave/ledger.cpp:320) [Enclave] Ledger: 	Group: Orderer
tlcc_enclave/enclave/ledger.cpp:341) [Enclave] Ledger: 		Org: SampleOrg
tlcc_enclave/enclave/ledger.cpp:353) [Enclave] Ledger: 			MSP Config: SampleOrg
tlcc_enclave/enclave/ledger.cpp:355) [Enclave] Ledger: 			\-> Root certs: 1
tlcc_enclave/enclave/ledger.cpp:365) [Enclave] Ledger: 			\-> Admin certs: 1
tlcc_enclave/enclave/ledger.cpp:347) [Enclave] Ledger: Can not decode protobuffer

... maybe due to outdated protobuf files?
The good part is that we don't do any error-handling and ignore all errors, i.e., all tests are fine (and from a "SDKIzation milestone" we are robust ); the bad part is of course we do not do proper error handling which is essential here in the long run (for this, though, there is also a separate meta-issue #138).
PS: Complete log file with more context: peer.err.txt

I am wondering if this also happens with Fabric v1.4.1.

I am wondering if this also happens with Fabric v1.4.1.

could be, i was wondering that as well.  But didn't have time to test that and in any case this seems to be a bigger work-item and probably better addressed when we do bigger clean-up in tlcc and/or when we move to 2.0.0-alpha/master ...

Fixed with  #147


chore(deps): update terraform github.com/terraform-ibm-modules/terraform-ibm-landing-zone to v5.29.1

This PR contains the following updates:

Package
Type
Update
Change

github.com/terraform-ibm-modules/terraform-ibm-landing-zone
module
patch
v5.29.0 -> v5.29.1

Release Notes

terraform-ibm-modules/terraform-ibm-landing-zone (github.com/terraform-ibm-modules/terraform-ibm-landing-zone)
v5.29.1
Compare Source
Bug Fixes

deps: update terraform ibm to latest for the landing zone das (#835) (f69aed8)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

/run pipeline

:tada: This issue has been resolved in version 1.4.22 :tada:
The release is available on:

GitHub release
v1.4.22

Your semantic-release bot :package::rocket:


(Docs) Add support for Llama2, Claude, Palm, Cohere, Replicate (100+ LLMs)

Hi @jackmpcollins @pachacamac
Noticed you're calling the openai chatcompletions endpoint. I'm working on LiteLLM (simplify LLM API Calls - https://github.com/BerriAI/litellm) and wanted to be helpful.
My PR shows users how to call their custom LLM providers (bedrock, togetherai, huggingface tgi, replicate, ai21, cohere, ai21 etc.) by pointing the api base to a local proxy they can use for experimentation with Magentic.
This makes no code changes to Magentic.
Happy to add additional tests/documentation if the initial PR looks good.

Hi @krrishdholakia I need to work out how magentic should deal with models that don't support function calling / structured output before I would be happy to add instructions for using these - otherwise most of magentic's features won't work with this setup. See discussion on PR https://github.com/jackmpcollins/magentic/pull/37. I will leave this PR open for the moment and revisit when this is worked out. Thanks

Added a note about the LiteLLM proxy server as part of PR https://github.com/jackmpcollins/magentic/pull/54 . See the Backend/LLM Configuration section of the README.


Avoid loading config files when executing the liveness probe check

Proposed change
Add a new configuration option that prevents the liveness probe command from loading config files.
Why?
It's possible, even common to end up Rails specific logic Racecar config files.
Racecar.config.logger = Rails.logger for example.
In these cases it's not desirable for the liveness probe to use the same configuration mechanism. A new option,RACECAR_LIVENESS_PROBE_SKIP_CONFIG_FILES ensures this doesn't happen.

@deepredsky I've changed approach on this a little, updated the readme and added to the changelog.


Add Mullvad VPN Detection

Mullvad VPN is another VPN client that causes connection issues.

Resolved with #20


posmod(0, 0) crashes the engine

Godot version:
$ godot --version
3.2.3.stable.custom_build.70db4e045

The only changes are setting max_physics_steps to 1024 and applying this patch (remove redundant newlines in TSCN): #39056
OS/device including version:
$ uname -a
Linux pc 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) x86_64 GNU/Linux

Issue description:
Adding posmod(0, 0) crashes the engine.
Steps to reproduce:
Execute this script with godot -s <filename>:
#!/usr/bin/env -S godot -s
extends MainLoop

func _idle(_delta):
	posmod(0, 0)
	return true

Judging by the backtrace it seems SIGFPE isn't correctly handled (signal 8 == SIGFPE)
Minimal reproduction project:
See above.
Backtrace
Godot Engine v3.2.3.stable.custom_build.70db4e045 - https://godotengine.org
OpenGL ES 3.0 Renderer: GeForce GTX 1060 6GB/PCIe/SSE2

handle_crash: Program crashed with signal 8
Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
[1] /lib/x86_64-linux-gnu/libc.so.6(+0x37840) [0x7fc7cac04840] (??:0)
[2] godot() [0x8b420e] (/home/david/Documents/Godot/GodotEngine/godot/./core/math/math_funcs.h:202)
[3] godot() [0x8ccff7] (/home/david/Documents/Godot/GodotEngine/godot/modules/gdscript/gdscript_parser.cpp:1764)
[4] godot() [0x8e8723] (/home/david/Documents/Godot/GodotEngine/godot/modules/gdscript/gdscript_parser.cpp:2030)
[5] godot() [0x8f1b8a] (/home/david/Documents/Godot/GodotEngine/godot/modules/gdscript/gdscript_parser.cpp:3445)
[6] godot() [0x8fe6d9] (/home/david/Documents/Godot/GodotEngine/godot/modules/gdscript/gdscript_parser.cpp:4107)
[7] godot() [0x90044b] (/home/david/Documents/Godot/GodotEngine/godot/modules/gdscript/gdscript_parser.cpp:8712)
[8] godot() [0x900d34] (/home/david/Documents/Godot/GodotEngine/godot/./core/os/memory.h:117)
[9] godot() [0x82d433] (/home/david/Documents/Godot/GodotEngine/godot/modules/gdscript/gdscript.cpp:593)
[10] godot() [0x832054] (/home/david/Documents/Godot/GodotEngine/godot/modules/gdscript/gdscript.cpp:2291)
[11] godot() [0x2ba0477] (/home/david/Documents/Godot/GodotEngine/godot/./core/cowdata.h:377)
[12] godot() [0x2ba0bbd] (/home/david/Documents/Godot/GodotEngine/godot/core/io/resource_loader.cpp:404)
[13] godot() [0x793069] (/home/david/Documents/Godot/GodotEngine/godot/main/main.cpp:1640 (discriminator 2))
[14] godot(main+0x74) [0x75dcf4] (/home/david/Documents/Godot/GodotEngine/godot/platform/x11/godot_x11.cpp:55)
[15] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7fc7cabf109b] (??:0)
[16] godot() [0x76051a] (??:?)
-- END OF BACKTRACE --
Aborted

Function - https://github.com/godotengine/godot/blob/90edd839d5f67d4252923a720feeef6ad0d76107/core/math/math_funcs.h#L201-L207

Confirmed that this is still reproducible as of 4.0 RC 1.


questions about discreteness in optimization

Hi! Thank you for the interesting paper.
While I was reading the paper, I'd like to ask you something I don't understand.
In 3.2 Optimization part of the paper,
If h is initialized with random distribution and then optimized with stochastic gradient descent (SGD),
which has been proved to only change the parameters in a small neighborhood (AllenZhu et al., 2019),
the optimizer would easily fall into local minima.

Is the problem with the discreteness of word embedding $e$ in the optimization? could you explain about this in more detail?
the second question is why the proposed prompt encoder encourage discreteness. maybe it might be connected to the first question.
Thank you.

@skygl Hi,
Thanks for your interest in P-tuning!
The discreteness here refers to how embedding be like in the embedding space. Since embeddings are vectors in the continuous space, and the gradient optimization may suffer from

only change the parameters in a small neighborhood

, at that time we supposed that some poor results we had achieved would be attributed to this optimization challenge (i.e., the prompt embeddings were only changed locally and were  not optimized enough). Prompt encoders serve as reparameterization (also used in prefix-tuning (Li & Liang, 2021)), which consist nonlinear activation functions to encourage output embeddings to be optimized to farther locations in the embedding space.
However, in recent months we gradually understand that, even without reparameterization, the embeddings are still being drastically changed by gradients. So our hypothesis at that time does not really hold that prompt embeddings without prompt encoders can not be optimized out of neighborhood . The optimization challenge still exists, but now we think it may lie in somewhere else along the training of P-tuning.
I am not sure if my answer is clear enough. If you have other questions, please feel free to ask.

@Xiao9905
Thanks for quick answers!
It helped me a lot to understand 👍


Add proper codeowners

We wan to have a separation of concerns in this repo so as not to ping someone unnecessarily I propose adding
@0x009922 as the code owner of the **/**.js
@outoftardis, @WRRicht3r  as the code owner of **/**.md
and myself as the code owner of **.

Sounds good to me.

Sounds good to me too.
Also I believe it could be just *.js and *.md without the **/

Mmm, I guess I am responsible for any code in this repo as well, because even *.md files are not plain Markdown files and could be extended with some functionality. For example, queries.md has some.
Btw, if to keep the initial plan, then not only *.js, but also *.ts, *.vue and... maybe anything which is not *.md )

what about src/* and *.md for me and @WRRicht3r, .vitepress/* and other config files/scripts for @0x009922?
I think we can manage manually adding @0x009922 as the reviewer when Markdown files contain certain changes that he'd have to approve. I'd choose this approach is there is a limited number of files that contain that type of functionality.

Also I am responsible for JavaScript guide (src/guide/javascript.md), so it might make sense for me to track it automatically too.

I'll create a pull request for this


To collect EdgeX specific metrics telemetry, and for start/stop/restart of services

Hi @cloudxxx8 , @cherrycl , @jumpingliu
In order to collect all metrics data and tools which can perform start, stop and restart of services, does EdgeX provides any such facility?
Please let me know for any suggestions. Thank you.

@dipshirajput I don't have any idea for this.

@cherrycl ok.
can I know why was SMA included in EdgeX earlier ?

In theory, if you want to control your services without docker, you can write your customized System Management Executor
https://docs.edgexfoundry.org/2.1/microservices/system-management/executor/Ch_SysMgmtExecutor/
The default System Management Executor is implemented to control docker containers.  It's just a reference implementation.
The tests for SMA just make sure the API of SMA works fine.

@cloudxxx8 I understand.
may I ask,

what was the requirement of SMA in EdgeX while it was introduced?
for what reason SMA is being deprecated now?

please help me get this clarity.

@cloudxxx8 @cherrycl
when I try this step manually, it gives me the below output but for some reason this output is not getting logged in mqtt-subscriber.log file.
**```
root@Linux-1:~# python3 /home/root/edgex-taf/TAF/utils/src/setup/mqtt-subscriber.py edgex-export Int64 arg &
[1] 1660
root@Linux-1:~# Connected to MQTT with result code 0
{"apiVersion":"v2","id":"499e878d-fcc2-4a25-8aa2-55accbb9024f","deviceName":"Random-Integer-Device","profileName":"Random-Integer-Device","sourceName":"Int64","origin":1653024864214188690,"readings":[{"id":"668319c4-4b65-4d4f-8651-c95f7a344251","origin":1653024864214188690,"deviceName":"Random-Integer-Device","resourceName":"Int64","profileName":"Random-Integer-Device","valueType":"Int64","value":"28"}]}
Got mqtt export data!!

please give me some suggestions for the same. Thanks.

Hi @cloudxxx8 @cherrycl when I try this step manually, it gives me the below output but for some reason this output is not getting logged in mqtt-subscriber.log file.
**root@Linux-1:~#** python3 /home/root/edgex-taf/TAF/utils/src/setup/mqtt-subscriber.py edgex-export Int64 arg &
[1] 1660
**root@Linux-1:~#** Connected to MQTT with result code 0
{"apiVersion":"v2","id":"499e878d-fcc2-4a25-8aa2-55accbb9024f","deviceName":"Random-Integer-Device","profileName":"Random-Integer-Device","sourceName":"Int64","origin":1653024864214188690,"readings":[{"id":"668319c4-4b65-4d4f-8651-c95f7a344251","origin":1653024864214188690,"deviceName":"Random-Integer-Device","resourceName":"Int64","profileName":"Random-Integer-Device","valueType":"Int64","value":"28"}]}
Got mqtt export data!!

please give me some suggestions for the same. Thanks.

@dipshirajput Is this question for metrics data?

Close this issue due to no activity. If you have further question, please file questions on Github Discussions (https://github.com/orgs/edgexfoundry/discussions). Thank you.


Not sure which one to use

It looks like there are two rpotter.py scripts, I take it we should use the one in the subdirectory?

The one in the subdirectory has a higher version number and it's the only one I've been able to use. The one in the subdirectory appears to be Python 2 and the other seems to be Python 3.


Connection lines do not change

target service: app.diagrams.net (v21.0.6)
issue: Connection lines do not change

Reproduced in Chrome 111.0.5563.65 (Official Build) (64-bit) and FF 111.0 (64-bit)
"Waypoints" change in the Format panel showing a seleted one but this change is not reflected on "Waypoints" in the toolbar.
https://user-images.githubusercontent.com/44292306/225409363-59c2bb83-3e42-4307-94ae-e800562f014f.mp4

The connection line selected from the toolbar was used as a global setting in previous versions.
Is there a way to use it as a global setting?

Thanks for the report. This will be fixed in the next release. (If updateDefaultStyle is false, which is the new default since v21.0.1, the global setting will be changed if the selection is empty.)


Add define that disables the cxx implementation

Adds a define that disables the cxx implementation. This is useful for projects that use a cxx compiler but wish to only use the c api

Thanks!


Passing block to f.label fails in 0.9.4

@alexch and I discovered that the following code works as expected in fortitude 0.9.3 but fails in 0.9.4. Seems something gets confused when you pass f.label both args and a block.
form_for(some_obj, url: some_path(some_obj)) { |f|
   ...
   f.label(field_name, value: answer_key) { text answer_text }

Stacktrace:
     ActionView::Template::Error:
       wrong number of arguments (0 for 1+)
     # ~/.rvm/gems/ruby-2.1.4/gems/fortitude-0.9.4/lib/fortitude/rails/yielded_object_outputter.rb:8:in `block in wrap_block_as_needed'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/helpers/capture_helper.rb:38:in `block in capture'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/helpers/capture_helper.rb:200:in `with_output_buffer'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/helpers/capture_helper.rb:38:in `capture'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/helpers/tags/label.rb:36:in `render'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/helpers/form_helper.rb:750:in `label'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/helpers/form_helper.rb:1585:in `label'
     # ~/.rvm/gems/ruby-2.1.4/gems/fortitude-0.9.4/lib/fortitude/rails/yielded_object_outputter.rb:33:in `method_missing'
     # ./app/views/histories/edit.html.rb:76:in `block (3 levels) in history_choice'
     # (eval):32:in `tag_div'
     # ./app/views/histories/edit.html.rb:75:in `block (2 levels) in history_choice'
     # ./app/views/histories/edit.html.rb:68:in `each'
     # ./app/views/histories/edit.html.rb:68:in `block in history_choice'
     # (eval):12:in `tag_fieldset'
     # ./app/views/histories/edit.html.rb:65:in `history_choice'
     # ./app/views/histories/edit.html.rb:18:in `block (2 levels) in content'
     # ~/.rvm/gems/ruby-2.1.4/gems/fortitude-0.9.4/lib/fortitude/rails/yielded_object_outputter.rb:10:in `call'
     # ~/.rvm/gems/ruby-2.1.4/gems/fortitude-0.9.4/lib/fortitude/rails/yielded_object_outputter.rb:10:in `block in wrap_block_as_needed'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/helpers/capture_helper.rb:38:in `block in capture'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/helpers/capture_helper.rb:200:in `with_output_buffer'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/helpers/capture_helper.rb:38:in `capture'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/helpers/form_helper.rb:434:in `form_for'
     # (eval):3:in `form_for'
     # ./app/views/histories/edit.html.rb:12:in `block in content'
     # (eval):32:in `tag_div'
     # ./app/views/histories/edit.html.rb:11:in `content'
     # (eval):3:in `run_content'
     # ~/.rvm/gems/ruby-2.1.4/gems/fortitude-0.9.4/lib/fortitude/widget/rendering.rb:35:in `block in render_to'
     # ~/.rvm/gems/ruby-2.1.4/gems/fortitude-0.9.4/lib/fortitude/rendering_context.rb:79:in `record_widget'
     # ~/.rvm/gems/ruby-2.1.4/gems/fortitude-0.9.4/lib/fortitude/widget/rendering.rb:33:in `render_to'
     # ~/.rvm/gems/ruby-2.1.4/gems/fortitude-0.9.4/lib/fortitude/rails/renderer.rb:38:in `block (2 levels) in render'
     # ~/.rvm/gems/ruby-2.1.4/gems/fortitude-0.9.4/lib/fortitude/rendering_context.rb:183:in `with_yield_block'
     # ~/.rvm/gems/ruby-2.1.4/gems/fortitude-0.9.4/lib/fortitude/rails/renderer.rb:37:in `block in render'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/helpers/capture_helper.rb:200:in `with_output_buffer'
     # ~/.rvm/gems/ruby-2.1.4/gems/fortitude-0.9.4/lib/fortitude/rails/renderer.rb:28:in `render'
     # ./app/views/histories/edit.html.rb:1:in `_app_views_histories_edit_html_rb__2472174839435550605_70144171257780'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/template.rb:145:in `block in render'
     # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/notifications.rb:159:in `block in instrument'
     # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
     # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/notifications.rb:159:in `instrument'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/template.rb:339:in `instrument'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/template.rb:143:in `render'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/renderer/template_renderer.rb:55:in `block (2 levels) in render_template'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/renderer/abstract_renderer.rb:38:in `block in instrument'
     # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/notifications.rb:159:in `block in instrument'
     # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
     # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/notifications.rb:159:in `instrument'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/renderer/abstract_renderer.rb:38:in `instrument'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/renderer/template_renderer.rb:54:in `block in render_template'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/renderer/template_renderer.rb:62:in `render_with_layout'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/renderer/template_renderer.rb:53:in `render_template'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/renderer/template_renderer.rb:17:in `render'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/renderer/renderer.rb:42:in `render_template'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/renderer/renderer.rb:23:in `render'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/rendering.rb:99:in `_render_template'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/streaming.rb:217:in `_render_template'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/rendering.rb:82:in `render_to_body'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/rendering.rb:32:in `render_to_body'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/renderers.rb:32:in `render_to_body'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/abstract_controller/rendering.rb:25:in `render'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/rendering.rb:16:in `render'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/instrumentation.rb:44:in `block (2 levels) in render'
     # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/core_ext/benchmark.rb:12:in `block in ms'
     # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/core_ext/benchmark.rb:12:in `ms'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/instrumentation.rb:44:in `block in render'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/instrumentation.rb:87:in `cleanup_view_runtime'
     # ~/.rvm/gems/ruby-2.1.4/gems/activerecord-4.1.10/lib/active_record/railties/controller_runtime.rb:25:in `cleanup_view_runtime'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/instrumentation.rb:43:in `render'
     # ~/.rvm/gems/ruby-2.1.4/gems/fortitude-0.9.4/lib/fortitude/rails/rendering_methods.rb:85:in `render_with_fortitude'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/implicit_render.rb:10:in `default_render'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/implicit_render.rb:5:in `send_action'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/abstract_controller/base.rb:189:in `process_action'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/rendering.rb:10:in `process_action'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/abstract_controller/callbacks.rb:20:in `block in process_action'
     # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/callbacks.rb:113:in `call'
     # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/callbacks.rb:113:in `call'
     # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/callbacks.rb:552:in `block (2 levels) in compile'
     # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/callbacks.rb:502:in `call'
     # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/callbacks.rb:502:in `call'
     # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/callbacks.rb:86:in `run_callbacks'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/abstract_controller/callbacks.rb:19:in `process_action'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/rescue.rb:29:in `process_action'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/instrumentation.rb:32:in `block in process_action'
     # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/notifications.rb:159:in `block in instrument'
     # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
     # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/notifications.rb:159:in `instrument'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/instrumentation.rb:30:in `process_action'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/params_wrapper.rb:250:in `process_action'
     # ~/.rvm/gems/ruby-2.1.4/gems/activerecord-4.1.10/lib/active_record/railties/controller_runtime.rb:18:in `process_action'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/abstract_controller/base.rb:136:in `process'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/rendering.rb:30:in `process'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/test_case.rb:595:in `process'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/test_case.rb:64:in `process'
     # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/test_case.rb:495:in `get'
     # ./spec/controllers/histories_controller_spec.rb:18:in `block (3 levels) in <top (required)>'

Harlan,
Thanks for the bug report!
I suspect you're exactly right. Unfortunately, I can't easily verify this right now, because I'm in the middle of hiking the Pacific Crest Trail this year, and all I have with me is my iPhone.
I can tell you that the bug almost certainly lies within the YieldedObjectOutputter (https://github.com/ageweke/fortitude/blob/master/lib/fortitude/rails/yielded_object_outputter.rb). When using Rails' form helpers, Fortitude wraps the returned object (the "f" in the code below) in one of these, which is what causes expressions like "f.label" to actually produce HTML output, rather than just returning it. (As you probably know, in ERb, you have to say <%= f.label … %>, which would translate to Fortitude/Erector code like "rawtext f.label …", which is not really what anyone wants to write. For most Rails helpers, Fortitude's helper declarations use :transform => :output_return_value (exact symbol name may vary) to take care of this, but obviously the form helpers are  more complex since they're methods on a different object.)
The YieldedObjectOutputter isn't very long. If you can find and fix the bug with a spec, I'll happily accept the pull request. Otherwise, I'm happy to tackle it when I get back in October (or if I'm in a trail town and have success SSHing from my iPhone into my AWS server and making it work from there).
Sorry I can't just hand you a fix right now…but hope this helps point you in the right direction!
Cheers,
Andrew

On Apr 23, 2015, at 11:24 AM, Harlan T Wood<EMAIL_ADDRESS>wrote:
@alexch and I discovered that the following code works as expected in fortitude 0.9.3 but fails in 0.9.4. Seems something gets confused when you pass f.label both args and a block.
form_for(some_obj, url: some_path(some_obj)) { |f|
...
f.label(field_name, value: answer_key) { text answer_text }
Stacktrace:
 ActionView::Template::Error:
   wrong number of arguments (0 for 1+)
 # ~/.rvm/gems/ruby-2.1.4/gems/fortitude-0.9.4/lib/fortitude/rails/yielded_object_outputter.rb:8:in `block in wrap_block_as_needed'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/helpers/capture_helper.rb:38:in `block in capture'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/helpers/capture_helper.rb:200:in `with_output_buffer'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/helpers/capture_helper.rb:38:in `capture'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/helpers/tags/label.rb:36:in `render'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/helpers/form_helper.rb:750:in `label'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/helpers/form_helper.rb:1585:in `label'
 # ~/.rvm/gems/ruby-2.1.4/gems/fortitude-0.9.4/lib/fortitude/rails/yielded_object_outputter.rb:33:in `method_missing'
 # ./app/views/histories/edit.html.rb:76:in `block (3 levels) in history_choice'
 # (eval):32:in `tag_div'
 # ./app/views/histories/edit.html.rb:75:in `block (2 levels) in history_choice'
 # ./app/views/histories/edit.html.rb:68:in `each'
 # ./app/views/histories/edit.html.rb:68:in `block in history_choice'
 # (eval):12:in `tag_fieldset'
 # ./app/views/histories/edit.html.rb:65:in `history_choice'
 # ./app/views/histories/edit.html.rb:18:in `block (2 levels) in content'
 # ~/.rvm/gems/ruby-2.1.4/gems/fortitude-0.9.4/lib/fortitude/rails/yielded_object_outputter.rb:10:in `call'
 # ~/.rvm/gems/ruby-2.1.4/gems/fortitude-0.9.4/lib/fortitude/rails/yielded_object_outputter.rb:10:in `block in wrap_block_as_needed'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/helpers/capture_helper.rb:38:in `block in capture'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/helpers/capture_helper.rb:200:in `with_output_buffer'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/helpers/capture_helper.rb:38:in `capture'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/helpers/form_helper.rb:434:in `form_for'
 # (eval):3:in `form_for'
 # ./app/views/histories/edit.html.rb:12:in `block in content'
 # (eval):32:in `tag_div'
 # ./app/views/histories/edit.html.rb:11:in `content'
 # (eval):3:in `run_content'
 # ~/.rvm/gems/ruby-2.1.4/gems/fortitude-0.9.4/lib/fortitude/widget/rendering.rb:35:in `block in render_to'
 # ~/.rvm/gems/ruby-2.1.4/gems/fortitude-0.9.4/lib/fortitude/rendering_context.rb:79:in `record_widget'
 # ~/.rvm/gems/ruby-2.1.4/gems/fortitude-0.9.4/lib/fortitude/widget/rendering.rb:33:in `render_to'
 # ~/.rvm/gems/ruby-2.1.4/gems/fortitude-0.9.4/lib/fortitude/rails/renderer.rb:38:in `block (2 levels) in render'
 # ~/.rvm/gems/ruby-2.1.4/gems/fortitude-0.9.4/lib/fortitude/rendering_context.rb:183:in `with_yield_block'
 # ~/.rvm/gems/ruby-2.1.4/gems/fortitude-0.9.4/lib/fortitude/rails/renderer.rb:37:in `block in render'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/helpers/capture_helper.rb:200:in `with_output_buffer'
 # ~/.rvm/gems/ruby-2.1.4/gems/fortitude-0.9.4/lib/fortitude/rails/renderer.rb:28:in `render'
 # ./app/views/histories/edit.html.rb:1:in `_app_views_histories_edit_html_rb__2472174839435550605_70144171257780'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/template.rb:145:in `block in render'
 # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/notifications.rb:159:in `block in instrument'
 # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
 # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/notifications.rb:159:in `instrument'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/template.rb:339:in `instrument'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/template.rb:143:in `render'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/renderer/template_renderer.rb:55:in `block (2 levels) in render_template'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/renderer/abstract_renderer.rb:38:in `block in instrument'
 # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/notifications.rb:159:in `block in instrument'
 # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
 # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/notifications.rb:159:in `instrument'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/renderer/abstract_renderer.rb:38:in `instrument'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/renderer/template_renderer.rb:54:in `block in render_template'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/renderer/template_renderer.rb:62:in `render_with_layout'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/renderer/template_renderer.rb:53:in `render_template'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/renderer/template_renderer.rb:17:in `render'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/renderer/renderer.rb:42:in `render_template'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/renderer/renderer.rb:23:in `render'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/rendering.rb:99:in `_render_template'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/streaming.rb:217:in `_render_template'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/rendering.rb:82:in `render_to_body'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/rendering.rb:32:in `render_to_body'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/renderers.rb:32:in `render_to_body'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/abstract_controller/rendering.rb:25:in `render'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/rendering.rb:16:in `render'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/instrumentation.rb:44:in `block (2 levels) in render'
 # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/core_ext/benchmark.rb:12:in `block in ms'
 # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/core_ext/benchmark.rb:12:in `ms'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/instrumentation.rb:44:in `block in render'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/instrumentation.rb:87:in `cleanup_view_runtime'
 # ~/.rvm/gems/ruby-2.1.4/gems/activerecord-4.1.10/lib/active_record/railties/controller_runtime.rb:25:in `cleanup_view_runtime'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/instrumentation.rb:43:in `render'
 # ~/.rvm/gems/ruby-2.1.4/gems/fortitude-0.9.4/lib/fortitude/rails/rendering_methods.rb:85:in `render_with_fortitude'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/implicit_render.rb:10:in `default_render'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/implicit_render.rb:5:in `send_action'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/abstract_controller/base.rb:189:in `process_action'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/rendering.rb:10:in `process_action'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/abstract_controller/callbacks.rb:20:in `block in process_action'
 # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/callbacks.rb:113:in `call'
 # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/callbacks.rb:113:in `call'
 # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/callbacks.rb:552:in `block (2 levels) in compile'
 # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/callbacks.rb:502:in `call'
 # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/callbacks.rb:502:in `call'
 # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/callbacks.rb:86:in `run_callbacks'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/abstract_controller/callbacks.rb:19:in `process_action'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/rescue.rb:29:in `process_action'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/instrumentation.rb:32:in `block in process_action'
 # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/notifications.rb:159:in `block in instrument'
 # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
 # ~/.rvm/gems/ruby-2.1.4/gems/activesupport-4.1.10/lib/active_support/notifications.rb:159:in `instrument'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/instrumentation.rb:30:in `process_action'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/metal/params_wrapper.rb:250:in `process_action'
 # ~/.rvm/gems/ruby-2.1.4/gems/activerecord-4.1.10/lib/active_record/railties/controller_runtime.rb:18:in `process_action'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/abstract_controller/base.rb:136:in `process'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionview-4.1.10/lib/action_view/rendering.rb:30:in `process'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/test_case.rb:595:in `process'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/test_case.rb:64:in `process'
 # ~/.rvm/gems/ruby-2.1.4/gems/actionpack-4.1.10/lib/action_controller/test_case.rb:495:in `get'
 # ./spec/controllers/histories_controller_spec.rb:18:in `block (3 levels) in <top (required)>'

—
Reply to this email directly or view it on GitHub.

The problem appears to be that method_missing in YieldedObjectOutputter is wrapping things unnecessarily. Because when wrap_block_as_needed is called from method_missing it passes in the method_names to the child block, the child block is treated as if it had yielded_methods_to_output set which causes issues.
The simple/hack solution would be to just change method_missing to be like this:
      def method_missing(method_name, *args, &block)
        if @method_names_hash[method_name.to_sym]
          if [:form_for, :fields_for].include?(method_name.to_sym)
            block = ::Fortitude::Rails::YieldedObjectOutputter.wrap_block_as_needed(@output_target, method_name, block, @method_names_hash.keys)
          end
          return_value = @yielded_object.send(method_name, *args, &block)
          @output_target.rawtext(return_value)
          EMPTY_RETURN_VALUE
        else
          @yielded_object.send(method_name, *args, &block)
        end
      end

The better solution would probably be to register a list of Rails helpers that provide their own yielded_methods_to_output in Fortitude::Rails::Helpers, then reference that list to see if the child block should be wrapped.
I'll see whether I can cook up a proper pull request doing as such.

Upon some further thought it might be simpler to just check if the block accepts any arguments:
if block && block.arity > 0
            block = ::Fortitude::Rails::YieldedObjectOutputter.wrap_block_as_needed(@output_target, method_name, block, @method_names_hash.keys)
          end

Karl — as I mentioned in my other reply, I'm back from hiking the PCT. I'll take a look at this issue soon. The YieldedObjectOutputter definitely could stand a little refinement and improvement, and this issue is a great case why.
I'll tackle this shortly and let you know!

Welcome back!
It's been a while since I was looking into it, but let me know if there's something I can help with.
I vaguely remember it being more than just this 1 case, but maybe only cause I tried to hack in formtastic support...

Just reviewing some code and wanted to chime in -- I'm monkeypatching @karlhe's code from https://github.com/ageweke/fortitude/issues/24#issuecomment-113296121 and it's working great :+1:.

I just submitted PR #37 with a test case for this issue, but here's the thing: the tests are passing, not failing.
@harlantwood / @karlhe: mind taking a look? https://github.com/ageweke/fortitude/pull/37

cc @alexch

This has been fixed in 0.9.5. Take a look at my comments on PR #37 for more color. :)


EIP-7251: Enable EIP7251 CI jobs

we should have enabled CI and fixed it before merging #3618 😱

ci/circleci: test-eip7251 job fails

going to take a look soon

closing in lieu of #3656


PMID:30639107

New term : decreased cell diameter at division
A cell population phenotype in which cells in a population divide with a smaller diameter than normal (i.e. compared to wild-type cells under the same conditions).
New term : increased cell diameter at division
A cell population phenotype in which cells in a population divide with a larger diameter than normal (i.e. compared to wild-type cells under the same conditions).
New term : decreased cell volume at division
A cell population phenotype in which cells in a population divides with a smaller volume than normal (i.e. compared to wild-type cells under the same conditions).
New term : increased cell volume at division
A cell population phenotype in which cells in a population divides with a greater volume than normal (i.e. compared to wild-type cells under the same conditions).
New term : increased cell surface area at division
A cell population phenotype in which cells in a population divide with a greater surface area than normal (i.e. compared to wild-type cells under the same conditions).

Hi  @PCarme
I was going to put
New term : decreased cell diameter at division
under "thin cell" exact synonym decreased cell diameter
but this is described as
A cell population phenotype in which cells in a population divide with a smaller diameter than normal (i.e. compared to wild-type cells under the same conditions).
Is there any reason this is a population term? or could it be
A cell morphology phenotype in which a cell has a smaller diameter (thickness; width) than normal at cell division.

OK, I am mid-release, so I will probably do these next week. Other terms will hopefully be available tomorrow.
v


soorgeon clean

we should add a:
soorgeon clean {task-name}

command that cleans up notebooks. The most basic version can just apply isort, and flake8.
A more sophisticated version can use the static analysis code that we already have to delete dead code, see  https://github.com/ploomber/soorgeon/issues/49

In cli.py, I will add the clean command with a similar structure as refactor with task-name and --deep (leaving this as TODO)

Check if tasks path exists, if not: => “tasks directory not found, please refactor first!”
Check if tasks/{task_name} exists, if not => “task {task_name} not found!”
Then run clean.basic_clean(): (implement basic_clean in a new file clean.py)

What should we use to run yapf and flake8. Do we use  os.system, subprocess or something else?

I will start to complete the implementation, but any early feedback is appreciated.

my original comment was inaccurate, flake8 only lints files, it does not fix them.  let's use black (https://github.com/psf/black) as it's become the standard and many packages install it, so there's a good chance a user already has it. If black has a Python API, let's use it, if not, let's use subprocess
the main challenge here is cleaning up notebooks (ipynb files). applying isort and black to py files is trivial, but it's not for ipynb files (which we should also support). I think the best way to do it is to load the ipynb file, convert it to py file (we can use jupytext for this), apply isort and flake8, then save back as ipynb
we should add isort and black as dependencies to setup.py

Black does not have a Python API, which will require us to generate intermediate .py files for notebooks.
I think it may be possible that users have run both soorgeon refactor nb.ipynb and soorgeon refactor nb.py. So I will clean both if there are both {task_name}.py/.ipynb.
To avoid overwriting .py files refactored from nb.py, I will use tempfile for intermediate .py files used for cleaning notebooks.

sounds good


Subliminal 0.7.5 or 0.8.0

Hi,
This is not really an issue but regarding the latest changes I'm wondering if I should stick with the branch 0.8.0-dev or go for 0.7.5 as some correction have been made on this branch.
Are you planning to merge the two branch (or at least the changes) ?
Regards

Yes, I plan to merge and maybe do some other major changes on 0.8.0 if need be.


return full error message when exception happens

If you throw an exception with error message, the error message will be IGNORED and replaced with a generic message like "Internal processing error getUserInfo". The pull request will append the ACTUAL error message to that message. e,g. "Internal processing error getUserInfo, error message: Cannot connect to database"

This is related to THRIFT-3607.

Thanks for explanation. In our case, we have a web server layer on top of many layers of backends which communicate in thrift, e,g.

web server -> backend A -> backend B -> backend C.

It will be very difficult for trouble shooting on the web server or backend A. Since we will never ever show exception message from the web server to the browser or client app, so there is no way to trigger an exception and see the details of the backend servers. I believe the developers of the web servers or API gateways have the responsibility to keep the details no leaking to the outside of the world. Enforcing security at the thrift layer is fine but I just hope there is an alternative or option to enable this.
Would you accept a global configurable variable for this?

In a project I work on that uses thrift, the company maintains a set of patches they pull (mostly from master, where defects have been fixed on top of 0.10.0) that they need to ship something that works for them.  If you need to change the core exception handling behavior for your project, you can always do so in your own release engineering workflow regardless of whether a patch gets accepted and merged upstream.  That said, you are always welcome to submit a patch, certainly.  There may be other folks who use thrift who would want the same option, perhaps for standing up a new service for internal QA and getting more rapid identification of issues during testing.

Yes, we probably keep a patch list for this. Thanks Jeking3.


expand the configuration to use 2 dtu devices

Hi, I am using a grid with two dtu's. Can you expand the configuration to use 2 dtu devices? The total value (or/abd dtu 1 + dtu 2 vaule) should be visible on the OLED SH1106. Tx. I am using the ESP32 version on the ESP32 WROOM Dev Kit. Tx.
Originally posted by @wesseli01 in https://github.com/ohAnd/dtuGateway/discussions/43

from #43  ...

only displaying a summary of connected DTUs - no power controlling
connection to each dtu can be alternating based on the dtu refresh cycle setting

open @wesseli01 :

which additions for which values should be done and shown?
=> the same current dtu1 values in the web front end for the 2nd

means what in your opinion in detail for web ui and display (both display types) ?

which powersetting should be shown, only the highest, an average between both, or ..?
=> current sum value (dtu1 + dtu2) on display

powersetting from my point of view means the percentage of the power limit for the inverter - why should it be useful to sum the percentage?
I'll close the discussion issue to detailing the needs/ wishes here...


Review information in currency_iso.json to ensure it's accurate

It looks like certain currencies listed in currency_iso.json have inaccurate values, specifically, some currencies are listed as having subunit_to_unit: 1, yet also have a non-null decimal_mark 🤔
Similarly, there seems to be some discrepancy between what character the browser's Number.toLocaleString API returns for certain locales, for instance, for be-BY, the thousands separator is ,, whereas it's listed in currency_iso.json as
(1235.50).toLocaleString("be-BY", {currency: 'BYR', style: 'currency', currencyDisplay: 'symbol'})
// "BYR 1,236"

However, looking at the data for the Intl.js polyfill, it looks like the thousands separator is listed as  , https://github.com/andyearnshaw/Intl.js/blob/master/locale-data/json/be-BY.json#L285 so I'm
not sure which is accurate 🤷♂

I'm pretty sure it's not. AFAIK the browser/OS data is from https://www.currency-iso.org/en/home/tables.html or https://www.unicode.org/repos/cldr/trunk/common/supplemental/supplementalData.xml (which uses the former as a basis)


Issue with loading Union related archives

More FYI, rather than actual issues. When OpenGothic load *.vdf from file system, game crashes with exception:
 for(auto& i:archives)
    inst->gothicAssets.merge(phoenix::vdf_file::open(i.name), false); // buffer_underflow here

Callstack:
0x00007ff67c54ed76: dbg::call_stack<64u>::collect(unsigned int) in C:\Users\mrsta\Downloads\opengothic_win\Gothic2Notr.exe
0x00007ff67c3cf1dc: CrashLog::dumpStack(char const*) in C:\Users\mrsta\Downloads\opengothic_win\Gothic2Notr.exe
0x00007ff67c3cf738: terminateHandler() in C:\Users\mrsta\Downloads\opengothic_win\Gothic2Notr.exe
0x00007fff739263f6: ZN10__cxxabiv111__terminateEPFvvE in C:\Users\mrsta\Downloads\opengothic_win\libstdc++-6.dll
0x00007fff73a22d43: ZSt9terminatev in C:\Users\mrsta\Downloads\opengothic_win\libstdc++-6.dll
0x00007fff73a2bf56: _cxa_throw in C:\Users\mrsta\Downloads\opengothic_win\libstdc++-6.dll
0x00007ff67c430819: phoenix::buffer::slice(unsigned long long, unsigned long long) const in C:\Users\mrsta\Downloads\opengothic_win\Gothic2Notr.exe
0x00007ff67c47a368: phoenix::vdf_entry::read(phoenix::buffer&, unsigned int) in C:\Users\mrsta\Downloads\opengothic_win\Gothic2Notr.exe
0x00007ff67c47aa5b: phoenix::vdf_file::open(phoenix::buffer&) in C:\Users\mrsta\Downloads\opengothic_win\Gothic2Notr.exe
0x00007ff67c47ac87: phoenix::vdf_file::open(std::filesystem::__cxx11::path const&) in C:\Users\mrsta\Downloads\opengothic_win\Gothic2Notr.exe
0x00007ff67c3b7c39: Resources::loadVdfs(std::vector<std::__cxx11::basic_string<char16_t, std::char_traits<char16_t>, std::allocator<char16_t> >, std::allocator<std::__cxx11::basic_string<char16_t, std::char_traits<char16_t>, std::allocator<char16_t> > > > const&) in C:\Users\mrsta\Downloads\opengothic_win\Gothic2Notr.exe

I've added simple try-catch handler to workaround issue, so here is the list of files that are failed to load:
unable to load archive: "D:/Games/Gothic II/Data/$Templates$/asmcl.dll"
unable to load archive: "D:/Games/Gothic II/Data/Union.vdf"
unable to load archive: "D:/Games/Gothic II/Data/$Templates$/ZUNIONUTILS.DLL"
unable to load archive: "D:/Games/Gothic II/Data/$Templates$/ZBINKFIX.DLL"
unable to load archive: "D:/Games/Gothic II/Data/$Templates$/ZMOUSEFIX.DLL"

Proposed change:
Can you add new dedicated type of exception, if *.vdf file signature does not match VDF_SIGNATURE_G* ?
Thanks!

Hi, thanks I'll look at it. I might just implement a proper parsing routine if I can find documentation :)

ZUNIONUTILS.DLL

@Try I've added the exception as requested. You can now catch phoenix::vdfs_signature_error for this specific error. Could you send over the VDF file that caused the error so I can investigate?

Could you send over the VDF file that caused the error so I can investigate?

Unfortunately can't. This bug was reported on worldofplayer.ru forum, so don't have the file on my side.
Lets assume for now that issue was fixed :)

I see. I'd still like to implement it so I'll keep this issue open :>

Bump: got the Union.vdf file.
Union.zip

Thanks, that helps out a lot!
I managed to find out, that it's a single entry in the VDF which is causing the problem: SYSTEM/ZBINKFIXOLD.DLL.
The entire archive looks like this:
_WORK
_WORK/DATA
_WORK/DATA/ANIMS
_WORK/DATA/ANIMS/_COMPILED
_WORK/DATA/ANIMS/_COMPILED/HUMANS_SKELETON-T_SPAWN.MAN
_WORK/DATA/ANIMS/_COMPILED/INVALID_SOURCE_FILE.MDL
_WORK/DATA/ANIMS/_COMPILED/INVALID_SOURCE_FILE.MDM
_WORK/DATA/ANIMS/_COMPILED/INVALID_SOURCE_FILE.MMB
_WORK/DATA/MESHES
_WORK/DATA/MESHES/_COMPILED
_WORK/DATA/MESHES/_COMPILED/INVALID_SOURCE_FILE.MRM
_WORK/DATA/SOUND
_WORK/DATA/SOUND/INVALID_SOURCE_FILE.OGG
_WORK/DATA/SOUND/INVALID_SOURCE_FILE.WAV
_WORK/DATA/TEXTURES
_WORK/DATA/TEXTURES/_COMPILED
_WORK/DATA/TEXTURES/_COMPILED/INVALID_SOURCE_FILE-C.TEX
SYSTEM
SYSTEM/ASMCL.DLL
SYSTEM/AUTORUN
SYSTEM/AUTORUN/MENU
SYSTEM/AUTORUN/MENU/ZUNIONMENU.D
SYSTEM/AUTORUN/UTILS
SYSTEM/AUTORUN/UTILS/ZUNIONTRIGGER.D
SYSTEM/AUTORUN/UTILS/ZUNIONVOB.D
SYSTEM/AUTORUN/ZBINKFIX.DLL
SYSTEM/AUTORUN/ZMOUSEFIX.DLL
SYSTEM/AUTORUN/ZPARSEREXTENDER.DLL
SYSTEM/AUTORUN/ZUNIONUTILS.DLL
SYSTEM/M3D
SYSTEM/M3D/MSSA3D.M3D
SYSTEM/M3D/MSSDS3D.M3D
SYSTEM/M3D/MSSDS3DH.M3D
SYSTEM/M3D/MSSDX7.M3D
SYSTEM/M3D/MSSEAX.M3D
SYSTEM/M3D/MSSRSX.M3D
SYSTEM/M3D/MSSSOFT.M3D
SYSTEM/OSTEAMWORKS.DLL
SYSTEM/STEAM_API.DLL
SYSTEM/ZBINKFIXOLD.DLL

That being said, there seems to be a lot of entropy in that file. When extracted as-is, all content is just random bytes and no structure can be found. The file tool reports a plain "data" format for all files in the archive.
I assume its some sort of compression or encryption but if it's compression I can't tell the type. I'll have to look into the Vdfs32g.dll Union ships with. That could take some time :)
Btw, I apologize for my absence this past week, I've been ill.

Btw, I apologize for my absence this past week, I've been ill.

Welcome back :D

When extracted as-is, all content is just random bytes and no structure can be found.

Yes, most likely it's compressed. Yet it's probably not worth it to chaise after compression algorithm - just as long as it's not crashing it's fine.

Yeah that looks like a custom implementation of Vdfs32g.dll. Just skimming I can already tell trouble ahead:

There might be mods using these features too since the custom VDF loader is the default.

just as long as it's not crashing it's fine.

That I can do. It'll be ugly but I'll just generate a zero-length entry if I detect an out-of-bounds condition.

Tested today on latest phoenix commit(36d8d5f5562f2126fdab7d7a8a5aee362a432e42) in master branch:
Load fine without Union.vdf, but with Union.vdf, game throws exception upon game loading:
loading error: buffer underflow at byte 6 while reading 225443840 additional bytes [context: slicing]
Stack-trace:
1   libstdc++-6!.cxa_throw
2   phoenix::buffer::slice          buffer.cc
3   phoenix::buffer::extract        buffer.hh
4   phoenix::animation::parse       animation.cc
5   Animation::Sequence::Sequence   animation.cpp
6   std::construct_at<Animation...  stl_construct.h
7   std::allocator_traits<std::...  alloc_traits.h
8   std::vector<Animation::Sequ...  vector.tcc
9   std::vector<Animation::Sequ...  vector.tcc
10  Animation::loadMAN              animation.cpp
11  Animation::Animation            animation.cpp
12  Resources::implLoadAnimation    resources.cpp
13  Resources::loadAnimation        resources.cpp
14  Resources::implLoadMeshMain     resources.cpp
15  Resources::implLoadMesh         resources.cpp
16  Resources::loadMesh             resources.cpp
17  Resources::loadSkeleton         resources.cpp
18  AnimationSolver::load           animationsolver.cpp
19  MdlVisual::load                 mdlvisual.cpp
20  Npc::load                       npc.cpp

Offended file, that been requested from archive: humans_skeleton-T_SPAWN.MAN

Right, that fails because the VDF is compressed and I don't handle that. Just loading and accessing the files is fine but trying to actually parse data from them (animations in this case) will fail unless the data is properly decompressed beforehand.

Application side, unfortunately is not aware of where compression been used. Is it possible to pretend, that compressed files are not in archive at all?

Maybe it would be possible but it would be unreliable. Afaik there is no way of telling if a file is stored as compressed or not so I would have to try loading the file to check whether it's compressed or not. Or I would have to try to detect the file type using binary chunk IDs (for example).
If you can't handle the error in a try-catch, I recommend just not loading the VDF at all.

If you can't handle the error in a try-catch, I recommend just not loading the VDF at all.

Yes, that's good solution, that I'm happy with. We probably need an api to test if VDF has compressed files.

Just my 2 cents to this matter. The modified dll talks about zipped files, so shouldn't it be possible to get a rather reliable variant by first checking the VDF version and then the file for signatures/magic words/patterns? Very likely a open algorithm was used here and ZIP means Deflate many cases.
I learned that the hard way when I extracted stuff from unknown binary data without any success and then was told that the first 4 Bytes of my file in question were the magic pattern for a LZ4 compression. Boom! Got my file. If the algorithm is fixed, the whole thing could be way easier to accomplish. This list is far from complete, but maybe... Just one of these like my LZ4 example are enough for a quiick and precise way to detect compressed files. https://en.wikipedia.org/wiki/List_of_file_signatures
Of course this is absolutely irrelevant to compatibility of the original games in any language or version that ever showed up, but if mods are in scope in the far future, this might show up again.

I was thinking about that initially, but I noticed none of the files had an obvious header. I did some more investigating and I did find something the could be considered a header.
At offset 0x18, in compressed files there will be the byte sequence 00 00 78 da which corresponds with ZLIB Best Compression (no preset dictionary) according to the Wiki page you linked. I tried extracting that part of the file and I can say that it was a success.
So it actually seems to be possible to detect this compression, I just didn't see those four bytes being the same everywhere. There is some data before that too but I haven't figured out what it means yet. I'm attaching a ZIP containing the first 50 bytes of all files in Union.vdf for reference. I'll look into implementing a check for this soon-ish unless one of you would like to do that earlier :)

For now added workaround for OpenGothic: checking vdf header: f22560e1
Assuming that union is always version 160 :)


chore: migrate from lerna to turborepo

Since lerna is unmaintained,
this PR is migrating the aws/jsii repository to turborepo,
and plain yarn workspaces commands (and wsrun) as replacements.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Did we decide against switching everything to build out of source?

No, but I'll do that separately, package-by-package.

Closing as lerna is no longer dead as Nrwl has taken over maintaining it.


[spk] deployment table has holes when a deployment is started by manually committing into HLD

As a: developer/operator/manager
I want: to view the deployment list for commits made into the source repo or HLD repo
So that: there are no holes in the table
Describe the solution you'd like:
Currently, there are a lot of holes in the table when a commit is made into the HLD manually, since there's no linking prior build and release.

We may want to consider adding the start time to the table at the very least, and somehow indicating the fact that the missing fields are not an error in the tool. Perhaps we could mark it with HLD commit in the service column to indicate that the service name is not known.
Acceptance Criteria:
Do some UX thinking around this area
Does this require updates to documentation?: No

@gemorris Does this issue make sense to you? cc @samiyaakhtar


updated the id type from string to long

changed from ´public IActionResult GetById(string id)´ to ´public IActionResult GetById(long id)´ in line 189.

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

@lincolnpires  Thanks!


v1.0 Checklist

Checklist

[ ] Conform Playground (#3)
[x] Improved controlled component support (e.g. material-ui select) (#19)
[ ] Better test coverage
[x] Simplify example setup (#23)
[x] Documentation website (#29)
[ ] Testing guide (a.k.a. How to test)
[x] Button value validation (#21)
[x] Better Boolean support (#5)
[x] Yup support (#15)
[x] Examples with create-react-app
[ ] Example with next.js
[ ] Setting up changeset (#2)
[x] Autofoucs on error (JS+No-JS) (#33)
[ ] File upload support
[ ] Improve array support (e.g. 2d array, custom constraint)
[ ] Allows combining list commands
[x] Async validation (#40)

Amazing work mate!
Would love to see that Testing guide (a.k.a. How to test) task completed!


Feature/mst storage

What is this pull request?
This pr provide part of the functionality for multi-signature transactions pipeline - state.
Why do you implement it? Why do we need this pull request?
The state is a representation of data for multi-signature transaction cooperation, that contains transactions and available to perform merge and diff operations for them.
Details/Features

There is not implemented yet correct diff on states.
Rework operator == for transactions
Add blob filler function to types

I  guess it will bi wise to create a file commands.hpp which includes all commands instead of doing this:
https://github.com/hyperledger/iroha/blob/b6bbd350187576401303c3aa4c3f14547e7a67ce/irohad/model/impl/model_operators.cpp#L18-L31

if command set is changed, there will be only one place where you have to add new command

@Warchant

I guess it would be wise to create a file commands.hpp which includes all commands instead of doing this.

Good point, but definitely outside this pr. Better create another pr with such refactoring

Codecov Report

Merging #597 into develop will decrease coverage by 0.15%.
The diff coverage is 33.09%.

@@            Coverage Diff             @@
##           develop    #597      +/-   ##
==========================================
- Coverage    44.85%   44.7%   -0.16%
==========================================
  Files          271     274       +3
  Lines        11200   11336     +136
  Branches      5909    6003      +94
==========================================
+ Hits          5024    5068      +44
- Misses         750     753       +3
- Partials      5426    5515      +89

Impacted Files
Coverage Δ

irohad/model/transaction.hpp
0% <ø> (ø)
:arrow_up:

irohad/model/impl/model_operators.cpp
37.38% <0%> (-2.24%)
:arrow_down:

...le/irohad/model/operators/model_operators_test.cpp
26.82% <0%> (ø)
:arrow_up:

...odule/irohad/multi_sig_transactions/state_test.cpp
13.15% <13.15%> (ø)

libs/common/types.hpp
58.9% <20%> (-1.97%)
:arrow_down:

.../multi_sig_transactions/storage/impl/mst_state.cpp
58.13% <58.13%> (ø)

...rohad/multi_sig_transactions/storage/mst_state.hpp
83.33% <83.33%> (ø)

... and 1 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a072171...14ac670. Read the comment docs.


varlens allele support is too slow

Running on anything more than a few thousand variants is painful. I think @armish gave up trying to do this with varlens since he has tens of thousands of variants. This could be improved.

Just to provide more context to this: my specific task was to extract number of reads covering a particular region of the genome and I had to perform this task thousands of times. Here is a really simple benchmarking result:
$ time varlens-reads --reads test/data/CELSR1/bams/bam_5.bam --locus chr22:46930257 |wc -l > /dev/null

real	0m5.191s
user	0m1.416s
sys	0m0.213s

$ time samtools view test/data/CELSR1/bams/bam_5.bam chr22:46930257-46930257 |wc -l > /dev/null

real	0m0.090s
user	0m0.021s
sys	0m0.003s

Though we should note that varlens is an over-kill for this particular need as it comes with way more features than needed for this laser-focused task ;)


Can't use Marker as a default clusterItemContent

I wanted to use default markers and change the color of the selected ones. But I can't use even a default Marker as a  clusterItemContent because of the error:
java.lang.IllegalArgumentException: width and height must be > 0
I can't change the size of the Marker because it doesn't have a Modifier parameter.  So, how can I change the color of the selected marker as before (or in more optimal way), disable titles, snippets etc.?
       clusterItemContent = {
            Marker(
                //icon = it.getMarkerDescriptor(selectedEvent == it)
            )
        }

fun getMarkerDescriptor(isSelected: Boolean = false): BitmapDescriptor? =
    if (isSelected) BitmapDescriptorFactory.defaultMarker(BitmapDescriptorFactory.HUE_AZURE) else null

P.S. If I use a custom icon, it drastically decrease performance (especially in debug mode). Is there a way to optimize it?
P.P.S. With a custom icon, I also can't disable snippets and title - only sending null in the data. (The way it doesn't show is to send true in onClusterItemClick)
            clusterItemContent = {
                Icon(imageVector = Icons.Filled.Abc, it.name)
            }

If you would like to upvote the priority of this issue, please comment below or react with :+1: so we can see what is popular when we triage.
@Psijic Thank you for opening this issue. 🙏
Please check out these other resources that might help you get to a resolution in the meantime:

Check the issue tracker - bugs and feature requests for Google Maps Platform APIs and SDKs
Open a support case - Get 1:1 support in Cloud Console.
Discord - chat with other developers
StackOverflow - use the google-maps tag

This is an automated message, feel free to ignore.

Similar issue on my end - using Marker as clusterItemContent results in java.lang.IllegalStateException: Invalid applier.

Hm, I see a huge performance difference in clustering about 1k of items. Even if I use a 990 bytes .webp Image as an item, it has about 3x time to re-cluster against default markers. And that time the UI is frozen even if I use Clustering in LaunchedEffect.
How can I make a selected marker different (change size and/or color) by defalut?

As for now the simplest way is to add a new marker with same position to the content:
val content: (@Composable () -> Unit) = {
    Clustering(
        items = currentItems,
        onClusterItemClick = {
            Timber.v("Marker clicked: ${it.name}")
            viewModel.selectItem(it)
            true
        }
    )

    selectedItem?.let {
        Marker(state = MarkerState(it.position), zIndex = 1f, icon =  BitmapDescriptorFactory.defaultMarker(
            BitmapDescriptorFactory.HUE_AZURE))
    }
}