Page MenuHomePhabricator

OpenAPI linter - performance and dev-ex improvements
Open, MediumPublic

Description

Performance optimizations:

  • Lazy loading of ruleset: Implement caching layer for Spectral ruleset to avoid reloading on each validation request. Currently the entire ruleset is reloaded per request - consider using an in-memory cache with TTL or file-watch invalidation strategy. This will scale better as the number of custom rules and functions grows.
  • Spec caching: Cache validation results for identical OpenAPI specs to avoid redundant Spectral computation. Use MD5 hash of the entire spec as cache key - when users modify the spec, the hash changes and automatically invalidates the previous cache entry, preventing stale results. Provides immediate benefits when validating the same spec multiple times (e.g., during development iterations).

Developer experience:

  • Split rule tests: Refactor monolithic rule.test.js into context-specific test files organized by validation domain (e.g., request-body.test.js, examples.test.js, etc.). Current file will become unwieldy as new rules are added - splitting now improves discoverability and reduces merge conflicts.

Original subtasks

Event Timeline

Notes from Estimation:

  • Assume a local cache for the linter for spec cacheing. Imagine a case where we can save the cache in another tool, potentially (maybe memCache).
  • Right now it is not particularly slow, but as we expand modules and implement as part of CI, it will be wasteful to recalculate every time.
  • Are there metrics that we can look into? For example, create a baseline for linting now, vs cached linting, then extrapolate for CI.
  • Similar pattern: MW has a concept of cacheing that is separate from the actual cache. Maybe we do not cache when running locally; null cache, potentially. The mechanism in toolforge vs CI could also be different. Maybe a pluggable/configurable cache mechanism, so that it can be enabled only where we want/need it?

Next steps: Split to separate tasks; cacheing should be explored separately from restructuring the files. May also need a research spike for cache baselining/investigation.

aaron triaged this task as Medium priority.Feb 20 2026, 6:09 AM