Frun1na opened a new issue, #6538: URL: https://github.com/apache/rocketmq-dashboard/issues/6538
### Before Creating the Bug Report - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) of this repository and believe that this is not a duplicate. - [x] This is a defect in RocketMQ Studio, not a usage question and not a defect in another Apache RocketMQ repository. - [x] I can reproduce this on the current `rocketmq-studio` branch, or I have stated the exact version I am running below. ### Studio Version branch: `rocketmq-studio` git commit id: `779b8c0e` deployed as: reproduced by unit tests against that commit ### Runtime Environment OS: Ubuntu on WSL2 MySQL: not applicable — the defect is the missing validation before the write; the test uses a stubbed repository browser (for UI issues): not applicable ### Connected RocketMQ Cluster RocketMQ version: not applicable — the K8s certificate registry is Studio-local access mode: not applicable deployment: not applicable ### Describe the Bug `K8sCertService.normalizeOptionalIdentity` (`server/.../cluster/k8s/K8sCertService.java:186-195`) only trims the value and rejects a blank one; it never bounds it to the column that stores it: - `rmq_k8s_certificate.k8s_id` and `.cluster` are `VARCHAR(128)` and `.issuer` is `VARCHAR(256)` (`db/schema.sql:166-169`), while `CreateCertDTO`/`UpdateCertDTO` declare no `@Size` for them. - A longer value therefore reaches the INSERT, MySQL rejects it (`Data too long for column`, surfaced as a `DataIntegrityViolationException`), and the API answers `500` — while the blank-value and certificate-type checks in the same method already answer `400`. - The merged instance fix #4713 (`InstanceService.requireTextWithin`) states the same rationale for `rmq_instance`: "Letting a longer value through does not store it: MySQL rejects the write, so the caller gets a 500 from the persistence layer instead of the validation error the name field already returns". The topic/group registration columns (#6087) and the cloud credential fields (#6007) were bounded the same way. ### Steps to Reproduce The defect is pinned by unit tests; no database is needed: ``` cd server mvn -B -ntp test -DforkCount=1 -Dtest=K8sCertServiceTest ``` `createCertShouldBoundTheTextFieldsToTheirColumnsTest` and `updateCertShouldBoundTheTextFieldsToTheirColumnsTest` build a request with `k8sId`/`cluster` of 129 characters and an `issuer` of 257 characters and assert `400` with the field name, plus that the repository is never written. Before the fix both fail with `Expecting code to raise a throwable.` — the values are accepted and reach the repository. `createCertShouldAcceptTextAtTheColumnWidthTest` is the control: values exactly at the column width must still be stored. ### What Did You Expect to See? The API should reject a value that does not fit its column with `400 Certificate <field> must not exceed <n> characters` before the INSERT, the way `rmq_instance` (#4713), the topic/group registration text (#6087) and the cloud credential fields (#6007) already do. ### What Did You See Instead? The request is accepted, the INSERT fails in the persistence layer, and the console shows a generic server error instead of naming the field and its limit. ### Additional Context A fix with regression tests follows in a pull request. The certificate PEM fields are `TEXT` payload columns (byte-counted) and the issuer of a supplied certificate is derived from its X.509 name, so neither is part of this bound. -- 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]
