Master integration into dev-upgrade-16 #9461
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
style: separate typedef from fn signature
## Description I've found myself adjusting whitespace in `packages/orchestration` jsdoc. @kriskowal reminded me of the prettier plugin, which wasn't enabled in that package. We had an opt-in list because of bugs encountered in the past, like unstable formatting. (E.g. adding a newline on each save). In the latest version I'm only seeing that behavior when there's `@typedef` mixed into a function signature definition, which isn't good form anyway. I expect whenever we see that behavior we can simply improve our Jsdoc to get around it. This bumps the plugin version to latest and adds several packages. One config change is to stop the `jsdocCommentLineStrategy` that defaulted to "singleLine", because it makes a single `* @import` comment turn into a single line and we almost always want it to be easy to add another line. I changed to "keep" instead of "multiline" so one can use the tighter format when they wish. ### Security Considerations n/a, whitespace and whitespace config ### Scaling Considerations " ### Documentation Considerations " ### Testing Considerations " ### Upgrade Considerations "
no ticket, incidental ## Description Simplify JsonSafe and ResponseTo types in orchestration package ### Security Considerations <!-- Does this change introduce new assumptions or dependencies that, if violated, could introduce security vulnerabilities? How does this PR change the boundaries between mutually-suspicious components? What new authorities are introduced by this change, perhaps by new API calls? --> ### Scaling Considerations <!-- Does this change require or encourage significant increase in consumption of CPU cycles, RAM, on-chain storage, message exchanges, or other scarce resources? If so, can that be prevented or mitigated? --> ### Documentation Considerations <!-- Give our docs folks some hints about what needs to be described to downstream users. Backwards compatibility: what happens to existing data or deployments when this code is shipped? Do we need to instruct users to do something to upgrade their saved data? If there is no upgrade path possible, how bad will that be for users? --> ### Testing Considerations <!-- Every PR should of course come with tests of its own functionality. What additional tests are still needed beyond those unit tests? How does this affect CI, other test automation, or the testnet? --> ### Upgrade Considerations <!-- What aspects of this PR are relevant to upgrading live production systems, and how should they be addressed? -->
…Case or snake_case
…response marshalling (#9447) closes: #9445 ## Description Uses `jsonp.Marshaller` with `OrigName: false` for response marshalling for `vlocalchain` queries and transactions to ensure responses sent to the JS side of the bridge are camelCase instead of snake_case. ### Security Considerations ### Scaling Considerations ### Documentation Considerations ### Testing Considerations Starts with new tests that have multiword response keys (e.g. `completion_time`/`completionTime`, `validator_address`/`validatorAddress`) to demonstrate current behavior. ### Upgrade Considerations `vlocalchain` has yet to be released, but this is important to land in the initial iteration to avoid future breaking changes.
Tell Mergify to remove noisy HTML comments in the PR description from the Git merge commit. As per the NOTE in [Mergify Template docs](https://docs.mergify.com/configuration/data-types/#template): > By default, the HTML comments are stripped from `body`. To get the full body, you can use the `body_raw` attribute.
- request to http://localhost:8081/chains/agoriclocal failed, reason: connect ECONNREFUSED ::1:8081
2024-04-11 17:25 3c29089
- combine starshipjs utils with e2e smart wallet utils - create patch for js-yaml - apply existing patch for node-fetch and force resolution
closes: #XXXX refs: #8896 ## Description - Creates `@agoric/multichain-testing` package outside of the yarn workspace - Provides a containerized, multi-chain testing environment for local and CI testing using [cosmology-tech/starship](https://github.com/cosmology-tech/starship/tree/devnet-0.2.2) - The current `config.yaml` includes agoric, osmosis, cosmos, and hermes relayers between each. A chain registry (served over http), faucet, and block explorer are also provided). - Provides an ava test setup for accessing a chain registry, creating wallets, and requesting faucet funds - Ports utilities from `@agoric/synthetic-chain` and `dapp-agoric-basics` that help towards a smart wallet client that can execute offers. ### Security Considerations ### Scaling Considerations Taking on some tech debt here wrt smart wallet utilities and being DRY, but we plan to address this in future. See #8963 ### Documentation Considerations README.md documentation for running the service is provided. ### Testing Considerations The goal of this PR is to build greater confidence in our software via automated testing with fully-simulated chains. ### Upgrade Considerations
- given the ChainInfo type is inferred from KnownChains, ensure the icqEnabled key is present on all cosmos chains to facilitate TS types
_follow-up_ ## Description Adds 'umee', on the list in #8879. ### Security Considerations ### Scaling Considerations ### Documentation Considerations ### Testing Considerations ### Upgrade Considerations
refs: #9153 ## Description This partially reverts the behavioral change from `deviceTools` from #9153. ### Security Considerations None ### Scaling Considerations None ### Documentation Considerations None ### Testing Considerations None ### Upgrade Considerations DeviceTools are bundled into device bundles, so we want to minimize difference between code executing and code on disk.
…ndler (#9507) refs: #8596 ## Description Reverts a behavioral change questioned in #8596 (comment), which was indeed not appropriate. If the reject handler is missing, it should result in an unhandled rejection. ### Security Considerations None ### Scaling Considerations None ### Documentation Considerations None ### Testing Considerations No coverage ### Upgrade Considerations Maintains currently deployed behavior on mainnet
Co-authored-by: Ikenna Omekam <ikenna@agoric.com>
closes: #9484 closes: #9497 ## Description - Changes the type of every return in `localchain.js` to `PromiseVow` - Uses `watch` for `.query()` and `.deposit()` methods and returns a `Vow` - Updates call sites outside `vat-localchain` to expect and unwrap PromiseVows (using `V`) ### Upgrade Considerations These changes better prepare us for upgrades - consumers will know to expect a `PromiseVow`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Integrating latest master into
dev-upgrade-16Security Considerations
Scaling Considerations
Documentation Considerations
Testing Considerations
Upgrade Considerations