lxbme opened a new pull request, #3434:
URL: https://github.com/apache/apisix-dashboard/pull/3434
**Why submit this pull request?**
- [x] Bugfix
- [ ] New feature provided
- [ ] Improve performance
- [ ] Backport patches
**What changes will this PR take into?**
Part of #3417 (Data-integrity section): "Labels widget splits on every `:` —
a label value containing a colon errors on any subsequent edit of the tag set
(`Labels.tsx`; split on first colon only)."
The Labels widget represents `{key: value}` labels as `key:value` tags, and
both its typing validator and its change handler split every tag on EVERY
colon, requiring exactly two parts. Verified against a live gateway: the Admin
API accepts and stores colon-containing label values (`{"registry":
"docker.io:5000"}` → 201) — registry addresses, times, ratios are all realistic
values. Consequences:
- such a value could not be typed into the dashboard at all (instant format
error);
- once such a label existed on a resource (created via the Admin API),
**any** edit of the tag set — adding or removing an unrelated tag — re-parsed
every surviving tag, errored on the colon-value one, and silently discarded the
whole change: the resource's labels were permanently uneditable from the
dashboard.
**Fix.** New input is parsed on the **first** colon (key and value must both
be non-empty — the Admin API rejects empty ones with 400, also verified). This
alone would not be safe, though: the Admin API even accepts colons in label
**keys** (`{"a:b": "c"}` → 201, verified), and `a:b:c` is genuinely ambiguous —
a blind first-colon re-parse would silently rewrite a stored `{"a:b": "c"}`
into `{"a": "b:c"}` on any unrelated tag edit, trading today's loud failure for
silent corruption. So the change handler first matches each tag string against
the current value's entries in joined `key:value` form and keeps matching
entries **verbatim**; only genuinely new strings are parsed. Stored labels can
only ever be kept or explicitly removed, never mutated as a side effect of
editing other tags.
Known limitation, disclosed: colon-in-key labels still cannot be *created*
through the dashboard input — unchanged from before (they errored), and the
API-created ones now survive editing instead of blocking it.
The conversion helpers live in `labels-conversion.ts`, extracted from the
component solely so they are unit-testable.
**Tests** (red on the unfixed build at the intended assertions, green after):
- Unit `labels-conversion.test.ts`: 13 cases — first-colon parsing, empty
key/value rejection, verbatim preservation of colon-key survivors across
add/remove, non-object tolerance, display join.
- E2E regression `form.labels-colon-value.spec.ts`: a route seeded with
`{"registry": "docker.io:5000"}` keeps an editable tag set (add a tag, save,
full label set persisted), and a new colon-value label can be typed in and
round-trips to the API.
Blast radius (the widget is used by every resource's Basic section and the
health-check request-headers field): full local e2e suite — **173 passed**, the
only failure being `stream_routes.show-disabled-error`, which cannot run
outside the repo's own compose project (documented environment limitation).
Unit tests 21/21, lint and build clean.
**Related issues**
Part of #3417 (please do not auto-close the tracking issue)
**Checklist:**
- [x] Did you explain what problem does this PR solve? Or what new features
have been added?
- [x] Have you added corresponding test cases?
- [ ] Have you modified the corresponding document? (no user-facing document
covers the labels widget)
- [x] Is this PR backward compatible? If it is not backward compatible,
please discuss on the mailing list first
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
