Skip to content

fix(bytedance): Layer Separation price badge never matches the size widget - #15370

Closed
christian-byrne wants to merge 1 commit into
feat/api-nodes/bytedance-layer-separationfrom
fix/bytedance-layer-separation-price-badge-case
Closed

fix(bytedance): Layer Separation price badge never matches the size widget#15370
christian-byrne wants to merge 1 commit into
feat/api-nodes/bytedance-layer-separationfrom
fix/bytedance-layer-separation-price-badge-case

Conversation

@christian-byrne

@christian-byrne christian-byrne commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

Targets feat/api-nodes/bytedance-layer-separation, the branch of #15351.

The bug

ByteDanceSeedreamLayerSeparationNode's price badge tests

widgets.size in ["1k", "1.5k"]

against a combo declared as

IO.Combo.Input("size", options=["auto", "1K", "1.5K", "2K"], default="auto", ...)

JSONata in is case-sensitive, so the condition is false for every value the widget can hold. The range_usd branch is therefore the only branch that ever renders — a user who explicitly picks 1K or 1.5K still sees $0.032 - $0.064 instead of the flat $0.032.

Reproduction

Evaluated with the same jsonata package the frontend uses to render the badge:

$ node -e "const j=require('jsonata'); const e='widgets.size in [\"1k\",\"1.5k\"]';
  (async()=>{for(const s of ['auto','1K','1.5K','2K']) console.log(s, await j(e).evaluate({widgets:{size:s}}))})();"
auto  false
1K    false
1.5K  false
2K    false

After this change:

auto   range_usd 0.032-0.064
1K     usd 0.032
1.5K   usd 0.032
2K     range_usd 0.032-0.064
undef  range_usd 0.032-0.064   (unchanged fallback)

Why $lowercase rather than rewriting the literals as ["1K", "1.5K"]

Both fix today's bug. $lowercase additionally survives a label-casing change to the combo, which is exactly the failure mode being fixed. Fallback behaviour for an absent/undefined widgets.size is unchanged (JSONata propagates undefined, the in test is false, the range branch renders).

Not changed — one open question for @bigcat88

2K currently falls into the range_usd 0.032 - 0.064 branch. If 2K is a known flat price (the range's max being exactly 2x the min suggests 0.064), the badge should say so. I did not guess at a billing number; please confirm and I will follow up, or fold it into this PR.

This is the item Christian raised in Slack (price badge is "2K" in one place and "2k" in another) and it blocks the pricing checkbox on #15351.

Testing

No Python-side test: the expression is JSONata and is only evaluated in the frontend, and this repo has no price-badge test harness. Verified with the jsonata package as shown above. ruff check clean.

API Node PR Checklist

Scope

  • Is API Node Change

Pricing & Billing

  • Need pricing update
  • No pricing update

If Need pricing update:

  • Metronome rate cards updated
  • Auto‑billing tests updated and passing

QA

  • QA done
  • QA not required

Comms

  • Informed Kosinkadink

The Layer Separation price badge tests `widgets.size in ["1k", "1.5k"]`,
but the `size` combo declares ["auto", "1K", "1.5K", "2K"]. JSONata `in`
is case-sensitive, so the condition is false for every selectable value
and the badge always renders the 0.032-0.064 range, including when the
user has explicitly picked 1K or 1.5K.

Normalise with $lowercase so the comparison holds regardless of the
label casing.
@christian-byrne

Copy link
Copy Markdown
Contributor Author

Retracting this — I was wrong, and closing it.

The premise is false. The frontend lowercases combo widget values before they reach the JSONata context: normalizeWidgetValue in src/composables/node/useNodePricing.ts returns String(raw).trim().toLowerCase() for COMBO (and again in the catch-all branch), and buildJsonataContext runs every declared dependency through it. So widgets.size is already "1k" / "1.5k" / "2k" / "auto" by evaluation time, and widgets.size in ["1k", "1.5k"] matches correctly. Verified against origin/main, not just this branch.

My reproduction was the bug: I evaluated the raw expression against {widgets: {size: '1K'}}, which is not the context the frontend builds. Lowercase literals in the expression are the house convention, not a mistake — see nodes_bytedance.py:917.

The real, narrower defect is that 2K falls through to the range_usd else-branch despite having a determined price, and that is already fixed by #15366 against the same base branch. Nothing here to keep.

Apologies for the noise, @bigcat88 — and please disregard the "price badge is always wrong" framing if it reached you from anywhere else.

@christian-byrne
christian-byrne deleted the fix/bytedance-layer-separation-price-badge-case branch August 7, 2026 00:57
@github-actions github-actions Bot locked and limited conversation to collaborators Aug 7, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant