Skip to content

fix(codegen): support permission-set, keyword properties, and record refs#342

Open
knasher wants to merge 1 commit into
atrium-rs:mainfrom
knasher:fix/codegen-robustness
Open

fix(codegen): support permission-set, keyword properties, and record refs#342
knasher wants to merge 1 commit into
atrium-rs:mainfrom
knasher:fix/codegen-robustness

Conversation

@knasher

@knasher knasher commented Jun 15, 2026

Copy link
Copy Markdown

Summary

atrium-codegen / atrium-lex have fallen behind the lexicon spec: running lexgen against the current bluesky-social/atproto lexicons either panics or emits non-compiling code. This PR makes the four minimal changes needed to regenerate atrium-api cleanly against the latest lexicons with no manual post-edits.

These are additive/robustness changes — they generalize existing special-cases and add handling for constructs that previously weren't supported. Generated output for lexicons that already worked is unchanged.

Changes

  • atrium-lex: add the permission-set user type. Skip permission-set-only schemas during generation (e.g. app.bsky.auth*), since they describe OAuth scopes rather than API data types and produce no Rust types.
  • Escape Rust keywords used as object property names via raw identifiers (e.g. matchr#match), generalizing the previous ref/type special-case to all keywords.
  • Resolve a ref to a record's #main to the generated Record type instead of the non-existent Main (e.g. com.atproto.lexicon.resolveLexicon referencing the com.atproto.lexicon.schema record).
  • Restrict the record.rs / client.rs aggregations to the configured namespaces, so out-of-scope lexicons that ship in the atproto repo (site.standard, internal.bsky, com.germnetwork, …) don't produce references to ungenerated modules.

Verification

Regenerated atrium-api against bluesky-social/atproto@3247279: lexgen succeeds and cargo build -p atrium-api --all-features passes with no manual edits. The resulting generated crate is in production use in downstream services (a firehose indexer and an API gateway).

I've intentionally kept this PR to the codegen changes only — the regeneration cadence and versioning are yours to drive. The full regen this unblocks (≈146 files) lives on my fork as a reference if useful, but isn't included here.

🤖 Generated with Claude Code

…refs

The codegen had fallen behind the lexicon spec, causing lexgen to fail or emit non-compiling code against current bluesky-social/atproto lexicons:

- atrium-lex: add the 'permission-set' user type; skip permission-set-only schemas during generation (e.g. app.bsky.auth*), since they describe OAuth scopes rather than API data types.

- Escape Rust keywords used as object property names via raw identifiers (e.g. 'match' -> r#match), generalizing the previous ref/type special case.

- Resolve a ref to a record's #main to the generated Record type instead of the non-existent Main (e.g. com.atproto.lexicon.resolveLexicon).

- Restrict the record.rs/client.rs aggregations to the configured namespaces so out-of-scope lexicons (site.standard, internal.bsky, com.germnetwork) don't reference ungenerated modules.

Verified by regenerating atrium-api against atproto@3247279: lexgen succeeds and 'cargo build -p atrium-api --all-features' passes with no manual edits.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@knasher

knasher commented Jun 15, 2026

Copy link
Copy Markdown
Author

For reference, the full regeneration this change unblocks (against bluesky-social/atproto@3247279) lives on my fork if it's useful to eyeball the downstream effect before you drive your own regen:

It's a breaking regen at the Rust source level (so semver-major), but the large majority is AT-Proto-compatible lexicon evolution — new optional fields, open-union additions, and a constraint relaxation on getServiceAuth.aud (format: did → plain string). Those only surface as source breaks because the generated enums aren't #[non_exhaustive] and the data structs have no Default. The genuinely incompatible removals are concentrated in the explicitly-unstable areas (app.bsky.unspecced.*, tools.ozone.*, chat moderation).

Happy to slice it differently if that helps your release process.

Copilot AI 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.

Warning

  • Copilot's review of this pull request may be incomplete because some of the changed files are excluded by your Copilot content exclusion settings. See Excluding content from Copilot for details.

Pull request overview

Updates atrium-lex and atrium-codegen to better align with the current Lexicon spec so lexgen can regenerate atrium-api cleanly against newer atproto lexicons (avoiding panics and non-compiling output).

Changes:

  • Add Lexicon support for permission-set defs and skip generating Rust output for schemas that only contain permission sets.
  • Register record NSIDs up-front so #main refs for record schemas can resolve to the generated Record type.
  • Restrict record/client aggregation generation to the configured namespaces to avoid emitting references to ungenerated/out-of-scope modules.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File Description
lexicon/atrium-lex/src/lexicon.rs Adds LexPermission / LexPermissionSet and a LexUserType::PermissionSet variant for parsing permission-set schema defs.
lexicon/atrium-codegen/src/lib.rs Computes record NSIDs and passes them into codegen token emission so record #main refs can target Record.
lexicon/atrium-codegen/src/generator.rs Skips permission-set-only schemas; filters record.rs and client.rs generation to the configured namespaces.
lexicon/atrium-codegen/src/token_stream.rs Changed in PR but excluded from review by org policy (content not available).
Files excluded by content exclusion policy (1)
  • lexicon/atrium-codegen/src/token_stream.rs

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants