Meeting Summary:
The meeting focused on reviewing several PRs and discussing versioning processes for the execution APIs. Simsonraj presented a PR adding new error codes for replacement transaction enterprise, which received positive feedback from Tullio and Sina. Felix reviewed and approved Mercy’s PR for txpool status, noting challenges with testing non-deterministic responses but confirming it could be merged. Zane discussed versioning approaches with Felix, clarifying that release versions would be tied to tagged releases rather than repository versions. Sina raised concerns about the data structure design in a feature PR, suggesting that required fields like deletion strategy should be made optional when resources are disabled, and proposed renaming deletion strategy to retention policy. The team agreed that client feedback would be needed on this PR, particularly through the ACDE call. Developer Uche mentioned having a PR related to engine API changes, which Felix confirmed should be discussed in the ACDE call due to its cross-client nature.
Click to expand detailed summary
Mercy opened the meeting and noted that Chase might be absent due to an emergency. Sina added an item to the agenda, and Simsonraj mentioned creating a PR for testing negative conditions and error codes, requesting feedback before finalizing it.
The team discussed a PR for adding a new error code for replacement transactions within ETH send raw transactions. Simsonraj explained that he added test generators for error code scenarios and confirmed the tests can be consistently replicated across clients without significant modifications. Tullio from Erigon indicated he would review the PR and found it acceptable. Simsonraj noted that once the PR moves to the Hive, it will begin enforcing error code compliance, including for GET which hasn’t implemented standardized error codes yet.
The team discussed auto-generated I.O. fixtures and error codes in Geth. Simsonraj explained that current error codes are being overwritten during generation due to limitations in GET’s system. Felix suggested implementing the necessary error conditions directly in Geth, and Mercy offered to create a pull request for this purpose. The team also briefly mentioned a GitHub pull request related to execution-apis, though the details were not fully discussed.
Felix and Mercy discussed reviewing a TS pool item (758) and addressed previous comments. They identified challenges with testing the TX pool due to the response format being an object with an address key, which makes validation difficult in the current testing framework. Felix noted that while the generator works fine, the tests may fail because the testing framework cannot properly handle the object shape and content validation, which depends on test ordering and leftover data from other tests.
The team discussed challenges with testing a transaction pool feature due to its non-deterministic nature, where test results depend on client policies and transaction handling. Felix explained that while the test would be difficult to validate fully, they could still merge the code and observe behavior, similar to how build block V1 already handles similar functionality. Chase confirmed they had recently merged a fix making the from-mempool specification only, and the team agreed to review the updated behavior. The discussion concluded with a brief mention of a separate pull request (docs add site versioning support by bomanaps · Pull Request #779 · ethereum/execution-apis · GitHub) related to fashion, which Mercy had discussed with Zane.
Zane and Felix discussed versioning strategies for execution APIs and OpenRPC documentation. They aligned on having a workflow where releases are tagged on execution APIs, with pre-compiled versions and test artifacts being attached as artifacts. Felix clarified that the OpenRPC document version could be rendered dynamically using a command line flag in the spec generator rather than hard-coding it in YAML. They agreed the GitHub action would handle tagging releases and generating artifacts without necessarily updating the YAML version directly.
Zane and Felix discussed the versioning process for API specifications, clarifying that the repository will always show version 0.0 for YAML files, which serve as input sources rather than containing the final specs. They agreed that spec versions will only be created during official releases, not for every commit, and the assembled spec branch is used by downstream consumers like Flashbots. Mercy raised a question about implementing a changelog, to which Felix and Zane responded that while it’s feasible, it would require manual or script-based analysis of API changes between versions, and would be separate from the spec itself.
The team discussed a PR related to resource representation in the execution APIs, with Sina raising concerns about the mandatory deletion strategy fields and suggesting they should be optional. Felix expressed support for the overall approach of modeling client resources but noted concerns about the deletion strategy implementation. The group agreed to escalate the discussion to the ACDE call for broader client team input, as it affects cross-client concerns. Additionally, a new participant introduced a PR related to the execution API, which was directed to be discussed in the appropriate Ethereum PM repository issue for the ACDE call.
Next Steps:
- Tullio: Review Simsonraj’s PR on error code testing
- Mercy: Create a PR for implementing standardized error codes in Geth
- Felix: Merge PR #758 (TX pool)
- Zane: Create GitHub action for tagging releases with version management
- Mercy: Include EF capability PR discussion in next ACDE call and report back
- Sina: Make comments on the EF capability PR regarding optional fields and deletion strategy
- Developer (Uche): Put comment on Ethereum/PM repository agenda for ACD to discuss engine API changes
- Developer (Uche): Consider placing engine API discussion on both ACDC and ACDE calls
Recording Access: