A generated struct embeds two types that each tag a field json:"id". What does encoding/json emit?

## Promotion first Embedding a struct type without a field name promotes its fields into the outer type. `encoding/json` follows that promotion literally: the inner type's exported fields are encoded **into the outer JSON object**, not into a nested one. ```go type Base struct { ID string `json:"id"` } type Item struct { Base Name string `json:"name"` } // json.Marshal(Item{Base{"a"}, "b"}) -> {"id":"a","name":"b"} ``` Three details of promotion are worth holding on to: - An embedded field of **pointer-to-struct** type is flattened the same way (a nil one contributes nothing). - An embedded field of **non-struct** type — say `type Weight int` embedded — is treated as an ordinary field whose name is the type name. - Give the embedded field a **JSON tag name** and it stops being flattened: ``Base `json:"base"` `` produces `{"base":{"id":"a"},"name":"b"}`. That is the deliberate way to nest. ## The conflict rules Flattening means two fields can end up claiming the same JSON name, and Go's ordinary promotion rules are not enough (they would make the program ambiguous only when you actually *reference* the field). `encoding/json` therefore defines its own resolution over the flattened set of candidates for a name: 1. **Depth wins.** The field at the shallowest depth is selected. A field declared directly on the outer struct is at depth 0 and always beats anything promoted from depth 1. 2. **At the shallowest depth, tags win.** If any of the tied fields carry a JSON tag name, only those are considered — untagged ones drop out, even if there are several of them. 3. **If exactly one candidate remains, it is used. Otherwise all of them are ignored, and no error occurs.** Two embedded types each declaring `json:"id"` land squarely in rule 3: both are at depth 1, both are tagged, neither dominates, so the name is dropped from the type's field list altogether. ## What that looks like in practice ```go type Meta struct { ID string `json:"id"` } type Audit struct { ID string `json:"id"` } type Record struct { Meta Audit } // json.Marshal(Record{}) -> {} ``` The behaviour is symmetric. On decode, an incoming `"id"` matches no field in the flattened set, so it is discarded and both `Meta.ID` and `Audit.ID` stay at their zero values — a field that quietly stops round-tripping, with a nil error on both sides. ## Why this is a code-generation problem specifically By hand, embedding two types with an overlapping tagged field is unusual enough to catch in review. Generated code makes it routine. A schema-to-struct generator commonly emits a shared base type — identity, timestamps, tenant — and embeds it into every generated struct. The day a schema itself declares a field named `id`, the generator emits a second `id` at the same depth in one of the embedded types, and that resource's identifier disappears from its JSON. Every other generated type is fine, which makes it look like a data problem rather than a structural one. `go vet`'s structtag analyzer does report duplicate json names — but it compares the tags written in a single struct declaration. In `Record` above, the two fields are `Meta` and `Audit`, neither tagged, and vet sees no duplication; simulating promotion across embedded types is outside what that check does. So the guard here is not vet. It is a **round-trip test over generated types**: marshal a fully populated value, unmarshal it back, and assert equality. A cancelled field cannot survive that, and the test is itself cheap to generate. ## The fixes, in order of preference 1. **Rename one of the tags.** If the two identifiers genuinely mean different things, they should not share a wire name: `json:"audit_id"`. This is usually a modelling smell being surfaced by the encoder. 2. **Nest one of them deliberately.** Tag the embedded field: ``Audit `json:"audit"` `` gives `{"id":"...","audit":{"id":"..."}}`. Depth resolves the conflict because the outer `id` is now the only candidate at depth 0 for that name. 3. **Stop embedding.** A named field, ``Audit Audit `json:"audit"` ``, is the same thing said explicitly, and it removes the promotion machinery from the reader's head. 4. **Shadow on purpose.** Declaring ``ID string `json:"id"` `` directly on the outer struct wins by depth and silences the conflict — but it is easy to read as an accident, so document it if you use it. ## What to remember under pressure Flattening is the default and nesting is opt-in; a name collision is resolved by depth, then by tag, and a tie at the end is silence rather than an error. The moment a field that "should be there" is missing from an embedded-heavy struct, stop reading the payload and draw the promoted field set.