Skip to content

fix(protobuf): generate valid scalar map fields - #298

Open
Shubham-Padkonde wants to merge 2 commits into
accordproject:mainfrom
Shubham-Padkonde:fix/protobuf-map-fields
Open

Shubham-Padkonde wants to merge 2 commits into
accordproject:mainfrom
Shubham-Padkonde:fix/protobuf-map-fields

Conversation

@Shubham-Padkonde

@Shubham-Padkonde Shubham-Padkonde commented Oct 26, 2026 •

Copy link
Copy Markdown

Related to #249.

Changes

Protobuf map fields now omit the illegal optional label and resolve Concerto scalar keys and values to their underlying Protobuf types. For example, an optional map from an Identifier extends String scalar to an Amount extends Double scalar now generates map<string, double> amounts = 1;.

Map fields also use the property name instead of the map declaration name, so two properties using the same map type no longer generate duplicate field names. Field numbers are unchanged. Scalar lookup uses the map's declaring model, including when that map is imported by another namespace.

Added four regression tests using real models and a protoc compilation regression. Updated the affected Protobuf snapshot and existing map tests.

Validation

  • The four new model tests failed before the fix and pass after it. The compiler regression failed before the fix with Field labels (required/optional/repeated) are not allowed on map fields and passes after it.
  • npm run build and npm run test:esm pass.
  • npm test: 701 passing, 52 pending; lint, dependency/lockfile checks, license checks and JSDoc pass. The command still exits nonzero on the repository-wide branch-coverage threshold (95.91% against 96%).
  • Unmodified base af4fa2568c0af3e501614079f1f35039e88dcfaa, tested separately with the same dependencies and tools: 696 passing, 52 pending, and the same 95.91% branch coverage / threshold failure. The threshold is unchanged in this PR.
  • Node 24.15.0 on Windows; the Protobuf checks used protoc 36.2. The 52 pending cases are existing skips or require unavailable external compilers.

Flags

Generated map property names change to match their CTO property names; consumers of generated source/JSON field names should account for that correction. This does not renumber fields.

The full HR verification cases remain skipped for existing empty-enum and other generator limitations. This PR addresses the map-field defects; it does not claim every HR schema now compiles or add support for DateTime map keys.

Author Checklist

  • DCO sign-off included in the commit.
  • Behavior covered by regression and compiler tests.
  • Commit message follows AP format.
  • No new public option or API; existing map output corrected.
  • Targets main from a fork branch.

November 10 review fix

DateTime map keys, including imported scalar aliases, now generate string keys because Proto3 does not permit Timestamp messages as map keys. DateTime values remain google.protobuf.Timestamp. Added direct and imported-scalar regression tests plus protoc validation.

All 703 tests pass, with 52 pending; both new tests fail before the fix. Lint passes. The full command still fails the branch-coverage threshold: 95.92% versus 96%; unchanged c174e6f also fails at 95.91% with 701 tests passing. No thresholds were changed. Published signed commit 281b9cd. Prepared with OpenAI Codex assistance.

Signed-off-by: Shubham Padkonde <shubhampadkonde12@gmail.com>
@mira-accord-project

Copy link
Copy Markdown

Thank you for this contribution, and welcome to the Accord Project. Apologies for the wait.

I have approved the CI runs, which were waiting for approval, so you should see the Build, Verify Codegen and CodeQL results shortly. A maintainer will review the change once they are in. If anything fails, please push a fix to this branch and we will take another look.

Drafted by an Accord Project agent, reviewed by a maintainer.

@Shubham-Padkonde

Copy link
Copy Markdown
Author

Thanks for approving the workflows. All 27 reported checks are now passing on c174e6f, including the Node 22/24 Linux, macOS and Windows matrix, protobuf verification, and CodeQL. The PR is ready for the maintainer review you mentioned.

@mira-accord-project mira-accord-project Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for this fix, Shubham, and for the care you took with it. Map fields now use the property name rather than the map declaration name, they no longer carry the invalid optional rule, scalar keys and values resolve through the map's own model file (so imported maps work), and the snapshot changes all follow from the fix. The new protoc check and the narrowed skip reason in cases.js are good additions. One case is still invalid Proto3: a map keyed by DateTime, or by a scalar that extends DateTime. Handling it, or deliberately documenting it, along with a test would make this ready for a maintainer's review.

Nothing blocking; some suggestions below. Findings: 1 should-fix, 1 nit.

  • nit · tests · test/codegen/fromcto/protobuf/maps.js: The new tests cover String keys with scalar and DateTime values, but not a DateTime key or a scalar extending DateTime as the key. That is the one key type still invalid in Proto3. A unit test for it, and a matching map in the protoc verification model in protobuf.validate.test.js, would catch this.

Automated review by Mira, an Accord Project agent, at c174e6f. Findings are labelled blocking, should-fix or nit; a maintainer makes the final call.

type = declaration.getType();
}
}
return ModelUtil.isPrimitiveType(type) ? this.concertoToProto3PrimitiveType(type) : type;

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should-fix · correctness

A map whose key is DateTime (or a scalar extending DateTime) still emits map<google.protobuf.Timestamp, V>. Proto3 only allows integral or string types as map keys, never message types, so protoc rejects this. Concerto permits String and DateTime keys, so the case is reachable and sits close to what this PR is fixing. Suggest mapping a DateTime key to string (an ISO-8601 representation) for the key position only, with a short comment explaining why, or otherwise documenting that such maps are unsupported. If you would rather leave it for a follow-up, please say so in the PR description.

Signed-off-by: Shubham Padkonde <shubhampadkonde12@gmail.com>
Copilot AI balanced review requested due to automatic review settings November 10, 2026 06:24

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.

@mira-accord-project mira-accord-project Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, Shubham-Padkonde, for the quick follow-up. The new commit addresses the earlier point about DateTime map keys: in key position both DateTime and scalars extending it now become string, while values stay google.protobuf.Timestamp, and the timestamp import is always written. Resolving scalars through the map's own model file means imported maps work too. Using the field name instead of the map declaration name, and dropping optional on map fields, also removes the name clashes and the invalid field rule. The unit tests in maps.js cover local and imported scalar keys, DateTime keys, and message and enum values, and the updated verification skip reason is now accurate. I found nothing further that needs changing. The earlier review thread on the DateTime key can be resolved, as it is now addressed. This looks ready for a maintainer to look at once the full test and verification workflows have run.

No problems found.


Automated review by Mira, an Accord Project agent, at 281b9cd. Findings are labelled blocking, should-fix or nit; a maintainer makes the final call.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Approval recommended

No active review issues remain for the Protobuf map-field generation changes.

No open issues 🎉

Review effort: Balanced

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants