New Issue Checklist
Issue Description
For storage adapter authors, Parse Server’s request idempotency / duplicate request suppression is currently gated by concrete storage adapter classes instead of storage adapter capabilities. promiseEnsureIdempotency() currently returns early unless the adapter is an instance of MongoStorageAdapter or PostgresStorageAdapter.
That makes the storage adapter contract inconsistent: _Idempotency itself is a Parse internal class and is bootstrapped by core initialization, along with the unique reqId index, but the middleware behavior is available only to hardcoded adapter classes. A third-party or future first-party adapter cannot opt into idempotency cleanly even if it supports the needed behavior.
Currently the only workaround is to masquerade as one of the built-in adapter classes or patch Parse internals, which is brittle.
A capability check flag or function would be cleaner as an explicit storage-adapter capability instead of an instanceof MongoStorageAdapter || instanceof PostgresStorageAdapter check.
Possible ways:
adapter.capabilities?.idempotency === true
// or
typeof adapter.supportsIdempotency === 'function' && adapter.supportsIdempotency()
// or built in method calls
adapter.ensureIdempotencyIndexes?.(...)
adapter.supportsRequestDeduplication === true
Steps to reproduce
- Implement or register a custom storage adapter that does not extend
MongoStorageAdapter or PostgresStorageAdapter.
- Make the adapter support the
_Idempotency class, object creation, and uniqueness on reqId.
- Configure Parse Server with active idempotency options
- Send two identical write requests with same request ID; the feature does not get used.
Actual Outcome
The idempotency middleware returns early before checking the configured paths because the adapter is not an instance of MongoStorageAdapter or PostgresStorageAdapter. Duplicate request is therefore not suppressed.
Expected Outcome
A storage adapter that explicitly declares idempotency support should be able to participate in request deduplication without extending MongoDB or PostgreSQL adapter classes.
Environment
Server
- Parse Server version:
alpha
- Operating system:
N/A
- Local or remote host (AWS, Azure, Google Cloud, Heroku, Digital Ocean, etc):
N/A
Database
- System (MongoDB or Postgres):
custom storage adapter
- Database version:
N/A
- Local or remote host (MongoDB Atlas, mLab, AWS, Azure, Google Cloud, etc):
N/A
Client
- SDK (iOS, Android, JavaScript, PHP, Unity, etc):
REST
- SDK version:
N/A
Logs
Relevant code paths:
src/middlewares.js
- promiseEnsureIdempotency() hardcodes MongoStorageAdapter / PostgresStorageAdapter
src/Controllers/SchemaController.js
- _Idempotency is defined as an internal/default class
src/Controllers/DatabaseController.js
- initialization enforces _Idempotency class existence
- initialization ensures uniqueness for _Idempotency.reqId
- expire/TTL idempotency index creation is also gated by Mongo/Postgres adapter checks
New Issue Checklist
Issue Description
For storage adapter authors, Parse Server’s request idempotency / duplicate request suppression is currently gated by concrete storage adapter classes instead of storage adapter capabilities.
promiseEnsureIdempotency()currently returns early unless the adapter is an instance ofMongoStorageAdapterorPostgresStorageAdapter.That makes the storage adapter contract inconsistent:
_Idempotencyitself is a Parse internal class and is bootstrapped by core initialization, along with the uniquereqIdindex, but the middleware behavior is available only to hardcoded adapter classes. A third-party or future first-party adapter cannot opt into idempotency cleanly even if it supports the needed behavior.Currently the only workaround is to masquerade as one of the built-in adapter classes or patch Parse internals, which is brittle.
A capability check flag or function would be cleaner as an explicit storage-adapter capability instead of an
instanceof MongoStorageAdapter || instanceof PostgresStorageAdaptercheck.Possible ways:
Steps to reproduce
MongoStorageAdapterorPostgresStorageAdapter._Idempotencyclass, object creation, and uniqueness onreqId.Actual Outcome
The idempotency middleware returns early before checking the configured paths because the adapter is not an instance of
MongoStorageAdapterorPostgresStorageAdapter. Duplicate request is therefore not suppressed.Expected Outcome
A storage adapter that explicitly declares idempotency support should be able to participate in request deduplication without extending MongoDB or PostgreSQL adapter classes.
Environment
Server
alphaN/AN/ADatabase
custom storage adapterN/AN/AClient
RESTN/ALogs
Relevant code paths: