Azure / Azure/azure-rest-api-specs
[BUG] Regular expressions don't adhere to JSON Schema recommendation to avoid lookahead/lookbehind
- Dominant language
- TypeSpec
- Stars
- 3.1k
- Forks
- 5.9k
- Avg merge
- 2d 22h
- Merged PRs (30d)
- 444
Description
### API Spec link
n/a
### API Spec version
n/a
### Describe the bug
A number of regular expressions in this repo express regex's with lookahead or lookbehind. These features are not universally supported by regular expression engines across languages and are [specifically discouraged by JSON schema](https://json-schema.org/draft/2019-09/json-schema-core#rfc.section.6.4)
> Furthermore, given the high disparity in regular expression constructs support, schema authors SHOULD limit themselves to the following regular expression tokens:
>
> - individual Unicode characters, as defined by the [JSON specification](https://json-schema.org/draft/2019-09/json-schema-core#RFC8259);
> - simple character classes ([abc]), range character classes ([a-z]);
> - complemented character classes ([^abc], [^a-z]);
> - simple quantifiers: "+" (one or more), "*" (zero or more), "?" (zero or one), and their lazy versions ("+?", "*?", "??");
> - range quantifiers: "{x}" (exactly x occurrences), "{x,y}" (at least x, at most y, occurrences), {x,} (x occurrences or more), and their lazy versions;
> - the beginning-of-input ("^") and end-of-input ("$") anchors;
> - simple grouping ("(...)") and alternation ("|").
For some examples of this see:
- [storage](https://github.com/Azure/azure-rest-api-specs/blob/main/specification/storage/resource-manager/Microsoft.Storage/stable/2024-01-01/queue.json#L542)
- [pipelineGroups](https://github.com/Azure/azure-rest-api-specs/blob/f0084be7caca4b0f1aa06d84dcd76dff339cf5e3/specification/monitor/resource-manager/Microsoft.Monitor/PipelineGroups/preview/2024-10-01-preview/pipelineGroups.json#L151)
There are a bunch more throughout the repo, these are just a few examples.
The lack of adherence to this guidance w.r.t. regex's limits tools ability to consume these fields if those tools are written in languages that don't support those features - Go being an example of a language that doesn't (by default at least) support lookahead/lookbehind.
### Expected behavior
The JSON schema recommendation is followed and lookahead/lookbehind are avoided. Many regular expressions that use lookahead/lookbehind can be rewritten to avoid it. For example the storage example given above can be rewritten as `^[a-z0-9]([a-z0-9]|-([a-z0-9]))+$`, which is the same assertion but without the encoded length constraints - but given that it already says minLength: 3 and maxLength: 63, that requirement is already covered. This results in a constraint that can be parsed by more tools without any loss.
### Actual behavior
n/a
### Reproduction Steps
n/a
### Environment
_No response_
Contributor guide
Research direction
Start with the linked storage and pipelineGroups JSON examples, then search the repository for regular expressions containing lookahead or lookbehind. Review each match against the JSON Schema recommendation and existing minLength or maxLength constraints. Done means the affected specifications use portable expressions without losing their intended constraints and validation checks pass.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- json, openapi
- Domain
- api
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100