fix: stop resolving Asia Pacific regions to a profile that has no current model - #77
Merged
Merged
Conversation
…rent model
`bedrockGeoPrefix` mapped every `ap-*` region to the `apac.` geography. That
prefix is real, which is what made the mapping look right, but it carries only
Claude 3.x and `claude-sonnet-4-20250514` — no current-family profile exists
under it. So `FAB_INFERENCE=bedrock` with `AWS_REGION=ap-*` resolved to
`apac.anthropic.claude-sonnet-5`, an id that does not exist, and every session
failed at its first call.
Read off `aws bedrock list-inference-profiles`, per region:
ap-southeast-2 au. global. (apac. present, no current model)
ap-northeast-1 global. (apac. and jp. present, likewise)
ap-southeast-1 global. (apac. present, likewise)
So ap-southeast-2 resolves to the `au.` country profile, and the rest cannot
resolve at all — they reach the current models only through `global.`.
`global.` is not selected automatically. It routes requests worldwide, and this
backend exists so that no inference token leaves the adopter's chosen boundary,
which makes it a jurisdiction decision rather than a fallback. The function
throws instead, names why `apac.` is not an option, and tells the operator to set
the role's model to the `global.` profile id if that trade is acceptable.
──────────────────── The escape hatch was broken too ────────────────────
`isBedrockModelId` recognised `us.`, `eu.`, `apac.` and `us-gov.` and nothing
else. `au.`, `jp.` and `global.` are equally real profile namespaces, so a role
pointed at `global.anthropic.claude-sonnet-5` was not recognised as a Bedrock id
at all — it fell through to the canonical-id lookup, missed, and threw "No AWS
Bedrock model id is mapped".
That is precisely the workaround the region error hands the operator, so the two
bugs composed: the geo map sent AP users to an explicit profile id, and the
prefix list then refused the one they were told to use. Both prefix lists now come
from a single `GEO_PREFIXES` constant.
Neither is reachable from the org's three deploy regions, which is why it went
unnoticed — but this is a reference client, and it documented behaviour it did
not have.
Mutation-tested both directions: reverting `ap-*` to `apac.` fails the two new
region cases, and shortening `GEO_PREFIXES` back to four fails the pass-through
case.
Co-authored-by: stxkxsbot <275011021+stxkxsbot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Found while verifying the region prose in a sibling repo — the prefixes it documented turned out not to exist, and checking them against the API surfaced two bugs here.
apac.carries no current modelbedrockGeoPrefixmapped everyap-*region toapac.. That prefix is real — which is what made it look right — but it carries only Claude 3.x andclaude-sonnet-4-20250514. SoFAB_INFERENCE=bedrockwithAWS_REGION=ap-*resolved toapac.anthropic.claude-sonnet-5, an id that does not exist, and every session failed at its first call.Read off
aws bedrock list-inference-profiles:au.global.apac.present, no current modelglobal.apac.andjp.present, likewiseglobal.apac.present, likewiseap-southeast-2 now resolves to
au.. The rest throw with the reason rather than resolving to something invalid.global.is deliberately not selected automatically: it routes worldwide, and this backend exists so inference stays in a chosen boundary. That is the operator's call, made explicitly by setting the role's model.The escape hatch was broken too
isBedrockModelIdrecognised four prefixes and notau.,jp.,global.. So a role pointed atglobal.anthropic.claude-sonnet-5fell through to the canonical-id lookup and threw "No AWS Bedrock model id is mapped" — which is exactly the workaround the region error recommends. The two bugs composed. Both lists now come from oneGEO_PREFIXESconstant.Neither is reachable from the org's three deploy regions, which is why it went unnoticed. But this is a reference client, and it documented behaviour it did not have.
Verification
npm test485 pass · coverage exit 0 · lint + format clean. Mutation-tested both directions: revertingap-*toapac.fails the two new region cases; shorteningGEO_PREFIXESfails the pass-through case.