ter:update --tags=a,b exits non-zero with a generic message, and only the first tag reaches TER:
[WARNING] Could not update meta information of extension nr_browser_ai.
Reason: An error occured on handling the request.
The same call without --tags succeeds.
The defect is on the server side and is tracked at extensions.typo3.org/ter#656, which carries the root cause, the reproduction and a patch. In short: TER inserts the tag relation, then asks that table for an identity value it cannot have, and the resulting exception is masked as a generic error — so the first tag is written, the rest are not, and the client sees only a failure.
Nothing about tailor's request needs to change. --tags as a single comma-separated field is exactly what the endpoint parses.
What remains actionable here
TER answers every masked exception with the same generic text, distinguished only by an error code that tailor currently discards:
{"status": 500, "code": 1603956982, "message": "An error occured on handling the request."}RequestService renders error_description ?? message and drops the rest, so the console line looks identical for unrelated defects. Reporting the code and the HTTP status alongside the message would have pointed at the masked exception on the first call, instead of requiring the behaviour to be reconstructed from repeated calls against the production TER.
PR #99 implements that:
[WARNING] Could not update meta information of extension my_ext.
Reason: An error occured on handling the request. (HTTP 500, code 1603956982)
Related: #96 and #97 document --tags. That guidance stands — multi-tag updates simply cannot succeed until the TER side is fixed.
ter:update --tags=a,bexits non-zero with a generic message, and only the first tag reaches TER:The same call without
--tagssucceeds.The defect is on the server side and is tracked at extensions.typo3.org/ter#656, which carries the root cause, the reproduction and a patch. In short: TER inserts the tag relation, then asks that table for an identity value it cannot have, and the resulting exception is masked as a generic error — so the first tag is written, the rest are not, and the client sees only a failure.
Nothing about tailor's request needs to change.
--tagsas a single comma-separated field is exactly what the endpoint parses.What remains actionable here
TER answers every masked exception with the same generic text, distinguished only by an error code that tailor currently discards:
{"status": 500, "code": 1603956982, "message": "An error occured on handling the request."}RequestServicerenderserror_description ?? messageand drops the rest, so the console line looks identical for unrelated defects. Reporting the code and the HTTP status alongside the message would have pointed at the masked exception on the first call, instead of requiring the behaviour to be reconstructed from repeated calls against the production TER.PR #99 implements that:
Related: #96 and #97 document
--tags. That guidance stands — multi-tag updates simply cannot succeed until the TER side is fixed.