https://www.boundaryml.com logo
🟡 Bug in BAML Go code generator affecting dynamic...
# questions
s
The 2-phase BAML schema generation and extraction, with dynamic types, unlocks a lot of use cases for us ! ran into a little hiccup when we tried the go variant of https://github.com/ai-that-works/ai-that-works/tree/main/2025-09-30-dyanmic-schemas The BAML Go code generator produces incorrect
Decode()
methods for classes marked with
@@dynamic
. The generated code initializes
DynamicProperties
but never populates it with the parsed field values, resulting in all dynamic fields being lost during deserialization. The generated
Decode()
method only initializes the map but never iterates through fields:
Copy code
go
func (c *Response) Decode(holder *cffi.CFFIValueClass, typeMap baml.TypeMap) {
    typeName := holder.Name
    if typeName.Namespace != cffi.CFFITypeNamespace_TYPES {
        panic(...)
    }
    if typeName.Name != "Response" {
        panic(...)
    }

    c.DynamicProperties = make(map[string]any)
    // BUG: Missing loop to iterate through holder.Fields!
}
Looking at BAML's own test files (
engine/generators/languages/go/generated_tests/dynamic_types/baml_client/types/classes.go
), classes with both static and dynamic properties correctly implement the field iteration:
Copy code
go
switch key {
        case "title":
            ....
        default:
            c.DynamicProperties[key] = baml.DecodeToValue(valueHolder)
        }
This suggests the template conditionally generates the loop only when there are static fields to switch on, but forgets to handle the pure-dynamic case. we have a workaround for now by adding a dummy static field bamlVersion int? to the Response class in baml_src:
Copy code
class Response {                                                                                                                      
    bamlVersion int?  // Workaround for BAML Go codegen bug                                                                             
    @@dynamic         
  }
v
oops! Thanks for flagging this 🙂
we should be able to patch this in next week's release!
i
spotted this by accident, this issue can be closed then https://github.com/BoundaryML/baml/issues/2432
a
fixed in 0.218.0