I SAID IT
WOULD ROT.
IT SHIPPED
ROTTEN.

ONE OBJECT, THREE DESTINATIONS

Write your own model class for ADK and you are handed a single config object with 35 fields on it. On the wire those fields go to three different places. A few sit at the top of the request, most belong in a nested block, and a handful mean something only to the client library and are rejected by the endpoint. Nothing on the type tells you which is which.

THE FAILURE IS A 200

Put the tools in the wrong half and nothing errors. The call returns 200 with a well formed answer in it. The tools are simply absent, so the model answers from memory instead of calling anything, and it reads like a model that decided not to use the tool. You go and rewrite your prompt. The bug is one dictionary key away and it never says a word.

A silent wrong answer costs more than a crash. A crash tells you where to look.

A MAINTAINER CHECKED IT

He cross-checked my field table against the client library's own converters and said it lines up. Then he suggested something better than my workaround: instead of flattening the config by hand, hand the whole thing to the converter the official library already uses on itself. He asked me to run it against the full field set before anything went up for review.

SO I RAN IT, AND IT CAUGHT ME

I built a config with 33 of the 35 fields populated and pushed it through. The split came out clean, and nothing was silently lost. It also showed that the table I had published the day before was wrong.

I said six fields go to the top level. It is eight. I had missed two, writing from the installed package, less than 24 hours earlier.

THAT SETTLED THE ARGUMENT

I had been asking for one of two things: a documented table, or a helper that does the split for you. My own table going stale inside a day answered it. A written list is a second copy of the truth and it drifts, which is the same failure as the hand-rolled dictionary every custom model class is already writing. So: the helper. One copy of the mapping, and it moves when the library moves.

I would rather write the version that cannot go stale than the version that documents the staleness.

OPENED AT THEIR ASK

He came back with all three: the helper rather than the docs, on the ADK object rather than in the client library, and go ahead and put it up. It delegates to the library's own converter, strips a private routing key that is a 400 if you send it, covers the one field that changes name in transit, and re-raises the library's validation error with the field that actually caused it so the message points at your code instead of somebody else's.

Thirteen tests. The one I care about walks every field on the config type and fails if a new one shows up that the helper cannot place. If the library grows a field and this thing cannot classify it, their build says so, instead of somebody finding out through a parameter that quietly went nowhere.