gnd: Fix add and unify subgraph scaffolding generators#6660
gnd: Fix add and unify subgraph scaffolding generators#6660incrypto32 wants to merge 11 commits into
add and unify subgraph scaffolding generators#6660Conversation
Collapse the duplicated code generation so init and add share one path, removing the forked add mapping generator that had drifted from the scaffold one: - a single sanitize_field_name in scaffold/naming.rs (three copies removed) - a single generate_event_handlers driven by a new ResolvedEvent model (passthrough for now); add's copy is deleted - shared SPEC_VERSION / MAPPING_API_VERSION constants and one to_kebab_case No behavior change: init output is byte-identical and add is unchanged.
`gnd add` generated mappings and manifest entries that referenced entity types it never declared, so codegen and build failed. Declare them, and tighten two edges: - append an entity type per new event to schema.graphql - error when the data source name already exists - only update networks.json when the file is present
Decide each event's entity name once in a resolution pass, then feed the schema, mapping and manifest generators from it: - disambiguate events overloaded within one ABI (Transfer, Transfer1) - on collision with an existing entity, rename with the contract prefix by default, or under --merge-entities reuse the entity without redeclaring it while still generating the handler, so the new contract's events are indexed instead of silently dropped Wires up the previously-dead --merge-entities flag.
Solidity integers narrow enough to fit an i32 (signed up to 32 bits, unsigned up to 24 bits) now map to GraphQL Int, matching the generated AssemblyScript event params; wider integers stay BigInt. Previously every int/uint became BigInt, which mismatched the bindings.
A parameter named `new`, `class`, etc. produced an entity field the generated AssemblyScript cannot declare. Suffix reserved words with `_`. gnd's existing field-name conventions (camelCase, eventId/eventType) are kept intentionally.
End-to-end check that two events sharing a name in one ABI produce distinct entities (Ping, Ping1) and handlers (handlePing, handlePing1) through the add path.
Move overloaded-event name disambiguation into a shared disambiguate_events helper used by both init's generators and add's resolve_events. init previously emitted duplicate entity types and handlers for an ABI with two same-named events; it now suffixes repeats (Ping, Ping1) the way add does.
The mapping wrote `entity.<field> = event.params.<raw-name>`, but the ABI codegen escapes reserved-word getters (`new` -> `new_`) and names unnamed params `param<index>`. So a parameter named `new`, or an unnamed parameter, produced a mapping referencing a getter that does not exist (or an empty accessor that did not compile). Mirror the binding's getter naming on the right-hand side via a shared event_param_accessors helper.
resolve_events treated only the manifest's mapping.entities as existing, so a type hand-written in schema.graphql but not listed in any mapping was not seen as a collision: add appended a duplicate `type` and codegen failed on the redeclaration. Union the @entity types parsed from schema.graphql into the collision set, since the schema is the real source of truth for declared types. Falls back to manifest-only if the schema is missing or unparseable.
sanitize_field_name shipped its own RESERVED_WORDS list, a subset missing default/for/instanceof/null/void. A param named e.g. `void` was left unescaped as the entity field, while the schema/ABI codegen escaped the member to `void_` via the shared list, so the mapping referenced a member that did not exist. Escape via crate::shared::handle_reserved_word so both sides use one list.
resolve_events checked the raw event name, so a disambiguated overload alias (e.g. Transfer1) that collides with an existing entity was neither renamed nor merged and silently redeclared the type. Check entity_name (the name we actually declare) instead.
| // Integer types - all map to BigInt for simplicity | ||
| t if t.starts_with("uint") || t.starts_with("int") => "BigInt", | ||
| // Integers: small widths fit in an i32 (GraphQL Int), the rest need BigInt. | ||
| t if t.starts_with("uint") || t.starts_with("int") => int_to_graphql(t), |
There was a problem hiding this comment.
Should we do something similar for Int8?
|
Part of me thinks we should not do the complicated renaming on collision, but I think it would force users to not use Here's also what Claude had to say, I think it caught a few corner cases of the renaming machinery; I think they are all pretty esoteric corner cases, not sure if it's worth addressing them.
|
2 participants
gnd addwas a drifted copy of theinit/scaffold code generation, and the copy never wroteschema.graphql— so adding a data source produced a subgraph that failscodegen/build. This unifies the two paths and fixes a cluster of related codegen bugs.The scaffolder now decides every event's names once (a
ResolvedEvent) and feeds one set of generators (schema, mapping, manifest), instead ofinitandaddeach rolling their own.What's fixed:
addnow writes the event entities toschema.graphql(the main bug)--merge-entities(previously a dead flag), keeping the handler so the new contract's events are still indexedTransfer,Transfer1) in bothaddandinituint8,int32, …) map to GraphQLIntinstead ofBigIntnew,class, …) are escaped so the generated code compilesadderrors on a duplicate data-source name, and only updatesnetworks.jsonwhen it existsCleanup:
Notes:
eventId) rather than graph-cli's (internal_id) — deliberate.