Found while verifying cf62936 (the safe_encode FrozenError fix) by regenerating ServiceNotificationRule in sialogic_portal and diffing against the hand-written schema from sialogic_portal PR #797. Two output quirks remain; neither blocks generation, but both produce schemas that need hand-editing afterwards.
1. Datetime columns produce an invalid OpenAPI type and format
Generated output for created_at / updated_at:
"created_at": {
"type": "datetime",
"format": "datetime",
"x-nullable": false
}OpenAPI has no datetime type, and the defined format string is date-time. Expected:
"created_at": {
"type": "string",
"format": "date-time",
"x-nullable": false
}Two contributing spots in lib/generators/jsonapi/swagger/swagger_generator.rb:
swagger_format maps when :datetime then 'datetime' — should be 'date-time'.swagger_type_from_column_type has no case for :datetime / :timestamp / :date / :time, so it returns nil and swagger_type falls through to the app's attribute_type_info (or :string). Whatever the app supplies (e.g. :datetime) is passed through verbatim rather than normalized to a valid OpenAPI type. Mapping temporal column types to 'string' there (with the format coming from swagger_format) would make the default correct regardless of what attribute_type_info says.
2. Array attributes silently default their item type to string
For an array attribute not backed by a DB column and whose attribute_type_info entry has no items_type, array_items_type falls back to :string:
return:stringifitems_type.blank?
Example: recipient_contact_ids (an integer-ID array attribute on the resource) is emitted as
"recipient_contact_ids": { "type": "array", "items": { "type": "string" } }when the correct schema is "items": { "type": "integer" }. The silent fallback makes a missing items_type declaration look like a deliberate string array, so the error only surfaces when a client validates against the schema. Options: warn when falling back, or fail the generation with a message naming the attribute so the resource author adds items_type to attribute_type_info.
Reference
The hand-written workaround schema these were diffed against: sialogic_portal config/schemas/openapi/types/service_notification_rules.schema.json (PR #797, Bitbucket).
Found while verifying cf62936 (the
safe_encodeFrozenError fix) by regeneratingServiceNotificationRulein sialogic_portal and diffing against the hand-written schema from sialogic_portal PR #797. Two output quirks remain; neither blocks generation, but both produce schemas that need hand-editing afterwards.1. Datetime columns produce an invalid OpenAPI type and format
Generated output for
created_at/updated_at:OpenAPI has no
datetimetype, and the defined format string isdate-time. Expected:Two contributing spots in
lib/generators/jsonapi/swagger/swagger_generator.rb:swagger_formatmapswhen :datetime then 'datetime'— should be'date-time'.swagger_type_from_column_typehas no case for:datetime/:timestamp/:date/:time, so it returnsnilandswagger_typefalls through to the app'sattribute_type_info(or:string). Whatever the app supplies (e.g.:datetime) is passed through verbatim rather than normalized to a valid OpenAPI type. Mapping temporal column types to'string'there (with the format coming fromswagger_format) would make the default correct regardless of whatattribute_type_infosays.2. Array attributes silently default their item type to
stringFor an array attribute not backed by a DB column and whose
attribute_type_infoentry has noitems_type,array_items_typefalls back to:string:Example:
recipient_contact_ids(an integer-ID array attribute on the resource) is emitted aswhen the correct schema is
"items": { "type": "integer" }. The silent fallback makes a missingitems_typedeclaration look like a deliberate string array, so the error only surfaces when a client validates against the schema. Options: warn when falling back, or fail the generation with a message naming the attribute so the resource author addsitems_typetoattribute_type_info.Reference
The hand-written workaround schema these were diffed against: sialogic_portal
config/schemas/openapi/types/service_notification_rules.schema.json(PR #797, Bitbucket).