Azure / Azure/azure-rest-api-specs

[BUG] Regular expressions don't adhere to JSON Schema recommendation to avoid lookahead/lookbehind

Open
#34,779 1 comment 0 reactions 0 assignees View on GitHub
bug
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.