Meeting Summary:
The team discussed RPC Standard Call 21 versioning proposals and implementation details, including GitHub releases, test updates, and documentation handling approaches. The discussion covered technical aspects of error code standardization, validation processes, and testing tools implementation across different repositories. The conversation ended with plans to address stalled pull requests through ACD meetings and welcomed new participant Ahmad Wilson who expressed interest in contributing to spec generation discussions.
Click to expand detailed summary
Mercy led a discussion on RPC Standard Call 21, focusing on the proposal for versioning that has been under consideration since the beginning of the year. Felix confirmed he had reviewed the proposal and outlined the process, noting that a GitHub release for V1 could be created at any time, with Felix taking responsibility for this task. The team discussed several pull requests, including PRs 753, 742, and 746, with Felix clarifying that the max use gas change in PR 746 should not be included in the initial V1 release as it requires further discussion and agreement on API changes before deployment.
Felix and Mercy discussed the release process for the spec, focusing on freezing the current version and updating the test runner to use the released version. Felix emphasized the importance of updating the tests to include the recently added block timestamp to the transaction object, which will ensure all clients like Nethermind and Geth pass the tests. They also discussed the need to handle versioning in the documentation website, with Felix suggesting the implementation of a version selector. Mercy deferred the documentation aspect to Zane for further implementation.
The team discussed implementing versioning for documentation, with Zane suggesting using DocuSource’s markdown generation and a sidebar approach, while Felix preferred a top-bar version selector for better integration with the release process. They clarified that the current documentation system uses GitHub Actions to deploy to GitHub Pages, though this has evolved from an earlier system that required a separate GHPages branch. The team agreed to discuss the implementation details offline, with Zane recommending using GitHub Actions to automatically build and deploy documentation when new releases are published.
Felix and Zane discussed the deployment process for GitHub pages and the storage of documentation files. Zane explained that the build process creates a directory in the CI’s staging area, which is then copied to GitHub’s servers for hosting. They also discussed the potential use of versioning features from DocuSaurus, with Zane suggesting that custom tooling scripts could be written in any language to manage documentation versions without relying on the existing npm build process.
Felix and Zane discussed approaches for handling API versioning in documentation builds. They explored options including using GitHub pages with a branch approach versus generating versions into the current repository. The team agreed on a three-step plan: updating tests to run on the new version, creating a GitHub release, and then modifying the docs build to be version-aware. When Zane asked about incorporating .ios test files into the docs for validation, Felix clarified that these files already undergo validity checks through existing jobs.
The team discussed error code standardization, with Simsonraj raising concerns about losing native validation functionality for error groups if the extension specification isn’t embedded in JSON. Felix explained that the motivation for recreating the spec build functionality was to gain better control over the YAML input format in the repository, though he acknowledged that supporting error groups could be implemented by updating their tool. Simsonraj demonstrated the current implementation, showing two generated files - one with references and one flattened version - and explained how error groups work in both versions, including the ability to natively validate error messages and codes against specified groupings.
The team discussed the implementation of error code validation in the OpenRPC specification. Felix suggested that validation could be handled through a tool during the spec generation process rather than embedding it in the spec itself. Simsonraj expressed concerns about re-implementing validations in multiple places if the current embedded approach was changed. Zane explained that the extensions framework was designed to allow flexibility for downstream consumers and help with versioning and testing. The team acknowledged that while the current PR has been open for a long time, there will likely be future changes to improve tooling and validation support.
Zane and Felix discussed the current state of testing tools and conformance testing for OpenRPC. Felix explained that their existing setup, including specific test chains and validation methods, works well for their needs and doesn’t require significant changes. They agreed to potentially move the test interpretation library into the Golang tools directory to make it easier for external projects to use. Mercy suggested creating a thread to further discuss and reach consensus on these tools, and Zane agreed to coordinate a meeting with LightClients to address this and other related topics.
The team discussed several stalled pull requests related to API specifications that require client consensus through ACD (All Core Developers) meetings. Felix advised that these proposals should be resubmitted as fresh PRs with minimal changes focused on method additions, rather than trying to revive old PRs with extensive comments. Mercy agreed to create a list of these proposals and introduce them one by one at future ACD meetings, with Felix offering to review the PRs before each meeting. The team also welcomed new participant Ahmad Wilson, who introduced himself as head of infrastructure at OTEM Labs and expressed interest in contributing to discussions around spec generation and error handling.
Next Steps:
- Felix: Create GitHub release of V1 for the RPC specification
- Felix: Update tests to include block timestamp changes to get clients back to 100% passing
- Mercy: Remove the third max use case PR from V1 release consideration
- Felix: Update test runner to use the released version of the spec instead of the latest one
- Zane: Provide direction on how to implement version selector in documentation website for browsing different spec versions
- Felix: Find someone to update the docs build to be aware of versioning and implement version selector
- Felix: Implement support for error groups in the spec generation tool
- Mercy: Create fresh PRs for stalled proposals (TX pool standardization, receipt proof, etc.) with links to old PRs
- Mercy: Introduce one proposal per ACDE meeting for client voting, starting with recreated PRs
- Mercy: Create call summary documenting versioning discussion and website issue as blocker
- Zane: Schedule and coordinate meeting with Felix (LightClient) to discuss testing infrastructure and requirements
- Felix: Move the I.O. file interpreter library into the Golang tools directory in the spec repository
Recording Access: