Describe the bug
The LeadingSingleCodePointEmojisInFields playbook incorrectly applies emoji string mutations to fields typed as boolean in the OpenAPI schema. It sends a string value (e.g. 🥶true) instead of a boolean, then expects a 2xx response — which is wrong.
To Reproduce
Steps to reproduce the behaviour:
- Have an OpenAPI spec with a POST endpoint containing a field typed as
"type": "boolean" (e.g. preauthorizationRequired)
- Run dochia with the
LeadingSingleCodePointEmojisInFields playbook against that endpoint
- Observe that dochia sends
"preauthorizationRequired": "🥶true" (a string with a leading emoji) instead of a boolean
- Dochia expects a
2xx response, but the API correctly returns 422 due to type mismatch
Expected behaviour
The LeadingSingleCodePointEmojisInFields playbook should only mutate fields with "type": "string". Fields typed as boolean, integer, number, etc. should either be skipped or sent with their correct type. When a boolean field is sent as a string, the expected result should be 4xx, not 2xx.
Environment:
Key | Value
--------------- | --------------------
OS Name | Mac OS X
OS Version | 26.2
OS Arch | aarch64
Binary Type | native
Dochia Version | 1.3.0
Dochia Build | 2026-0
Relevant OpenAPI section:
preauthorizationRequired:
type: boolean
description: whether the preauthorization is required; available only if shoptet pay module is enabled
examples:
- true
Additional context
Dochia sent:
"preauthorizationRequired": "🥶true"
instead of:
"preauthorizationRequired": true
Also similarly, with uuid format --> dochia generates "guid": "👩🏾1b02cb8e-d7b5-11e0-9a5c-feab5ed617ed", even if "format": "uuid" is specified (and pattern) and expects 2xx, but 422 is correctly returned via API.
"typeGuid":
"type": "string"
"format": "uuid"
"maxLength": 36
"pattern": "^[0-9a-f]{8}-([0-9a-f]{4}-){3}[0-9a-f]{12}$"
"examples": ["1b02cb8e-d7b5-11e0-9a5c-feab5ed617ed"]
OpenAPI file: https://api.docs.shoptet.com/_bundle/Shoptet%20API/openapi.yaml
Describe the bug
The
LeadingSingleCodePointEmojisInFieldsplaybook incorrectly applies emoji string mutations to fields typed asbooleanin the OpenAPI schema. It sends a string value (e.g.🥶true) instead of a boolean, then expects a2xxresponse — which is wrong.To Reproduce
Steps to reproduce the behaviour:
"type": "boolean"(e.g.preauthorizationRequired)LeadingSingleCodePointEmojisInFieldsplaybook against that endpoint"preauthorizationRequired": "🥶true"(a string with a leading emoji) instead of a boolean2xxresponse, but the API correctly returns 422 due to type mismatchExpected behaviour
The
LeadingSingleCodePointEmojisInFieldsplaybook should only mutate fields with"type": "string". Fields typed as boolean, integer, number, etc. should either be skipped or sent with their correct type. When a boolean field is sent as a string, the expected result should be4xx, not2xx.Environment:
Relevant OpenAPI section:
Additional context
Dochia sent:
"preauthorizationRequired": "🥶true"instead of:
"preauthorizationRequired": trueAlso similarly, with
uuidformat --> dochia generates"guid": "👩🏾1b02cb8e-d7b5-11e0-9a5c-feab5ed617ed",even if"format": "uuid"is specified (and pattern) and expects2xx, but422is correctly returned via API.OpenAPI file: https://api.docs.shoptet.com/_bundle/Shoptet%20API/openapi.yaml