fix: widen DynamicResourceDoc example/response body columns to text- #94 - #2898
Open
hongwei1 wants to merge 3 commits into
Open
fix: widen DynamicResourceDoc example/response body columns to text- #94#2898hongwei1 wants to merge 3 commits into
hongwei1 wants to merge 3 commits into
Conversation
ExampleRequestBody, SuccessResponseBody and ErrorResponseBodies were capped at varchar(255), which a realistic multi-field JSON example routinely exceeds even with minimal values. Endpoints with wider payloads had to omit the example entirely, leaving the request-body editor empty for API consumers instead of pre-filled. Widen all three to unbounded text, matching MethodBody's existing type. On an existing database this needs an explicit ALTER COLUMN migration (Schemifier only creates missing tables/columns, it does not widen existing ones), added as MigrationOfDynamicResourceDocBodyFieldsLength and wired into the existing migration-scripts pipeline. Verified: DynamicResourceDocTest, MigrationsTest, ResourceDocsTest, SwaggerDocsTest and SwaggerFactoryUnitTest all pass; manually confirmed the migration runs cleanly against a live Postgres instance and widens the columns to text.
Class.getCanonicalName() returns null for a local or anonymous class. A nested case class declared inside a runtime-compiled dynamic-endpoint method body is exactly that from the JVM's perspective, so any example body with a nested object (once the previous varchar(255) limit no longer forces such examples to be omitted) crashed the entire resource-docs listing with a NullPointerException, not just the endpoint that declared the nested field. Default to false (not an Option-typed field) when no canonical name is available, matching Option's own canonical name always being present since it is a top-level class.
…-body-length fix: widen DynamicResourceDoc example/response body columns to text
|
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.
Summary
DynamicResourceDoc.ExampleRequestBody,SuccessResponseBodyandErrorResponseBodieswere allMappedString(this, 255)(varchar(255)). A realistic multi-field JSON example — even with minimal values — routinely exceeds 255 characters once a payload has more than a handful of fields (field names alone can exceed the limit). Endpoints with wider payloads had no way to register an example at all via the runtime registration API, leaving API-Explorer-II's request-body editor empty for those endpoints instead of pre-filled, forcing API consumers to hand-type the JSON body from scratch every time.Widening the columns then surfaced a second, more serious bug: any example body with a nested object crashed the entire resource-docs listing (all endpoints, not just the one with the nested field) with a NullPointerException. Both are fixed here.
Fix
ExampleRequestBody,SuccessResponseBody,ErrorResponseBodiesfromMappedString(this, 255)toMappedText(this)(unbounded), matching the existingMethodBodyfield's type.MigrationOfDynamicResourceDocBodyFieldsLength, following the exact pattern of the existingMigrationOfTransactionRequestAttributeValueType(same scenario: varchar(255) too small for JSON-shaped content), and wired it intoMigration.database.executeScripts.Class.getCanonicalName()inJSONFactory1_4_0.checkFieldOption.getCanonicalName()returns null for a local or anonymous class — which is exactly what a nested case class declared inside a runtime-compiled dynamic-endpoint method body is, from the JVM's perspective. Once (1) stopped forcing such examples to be omitted, any example body with a nested object (e.g.{"payer": {...}}) hit this and took down/resource-docs/.../obpfor the whole API surface. Defaults tofalse(not Option-typed) when no canonical name is available.Test plan
DynamicResourceDocTest(8/8),MigrationsTest(12/12),ResourceDocsTechnologyTest,ResourceDocsTest,SwaggerDocsTest,SwaggerFactoryUnitTest(102/102 total across the six suites) pass\d dynamicresourcedocthat all three columns are nowtextGET /resource-docs/OBPv7.0.0/obpreturns 200 with all examples populated (previously 500 before the second fix, and previously omitted from the payload entirely before the first fix)textdirectly via Schemifier, and an existing database picks up the widening via the migration on next boot