In a versioned bucket, HEAD on a key whose latest version is a delete
marker returns 405 MethodNotAllowed instead of 404. GetObjectSizeAsync
threw on it, so re-adding a previously deleted attachment (same hash,
same key) failed with a 500 before the upload started.
* sync: keep pushed ciphers as UTF-8 from the hub to MongoDB
Pushed ciphers were parsed into strings, then encoded back to UTF-8 by
the driver into a new buffer for each large one: the two largest
sources of large object heap allocations on prod.
PushItems now reads each cipher straight into a pooled UTF-8 buffer and
UpsertMany writes the item's BSON itself, from that buffer, into another
pooled one. The stored documents are unchanged. Validation moves to
SyncItemValidator, and the base64 check is vectorized.
* sync: hand back pushed buffers when a push is rejected
The hub disposed the pushed items only after its own checks, and the
authorization filter rejects a call after SignalR has bound it, so those
rejections left their pooled buffers to the GC. A push with null items
also made the cleanup throw over the real error.
* api: drop the MessagePack hub protocol
* sync: fetch items in size-bounded chunks and send them as stored
* sync: label fetch failures by reason and log rejected connections at info
* sync: count rejected connections and cover fetch failure reasons and mid-fetch resets
Rejections are logged at Information, which production filters out, so a
counter by stage is what shows them. Also drops a catch around the no-op
Hub.OnDisconnectedAsync.
* api: purge reset data in the background
Resetting a large account deleted every sync collection in one Mongo
transaction, which outlived Mongo's time limit and the request timeout.
A reset now deletes the small collections (inbox keys and items,
monographs, devices) inline and then, in one settings update, clears the
keys, increments the user's Generation and marks a purge as pending.
Sync items are stamped with the generation they were pushed in, and
fetches and the encryption verifier only see the current one, so the old
data disappears as soon as the request returns. UserPurgeJob deletes the
older generations one collection at a time and clears the pending mark
only if no newer reset happened meanwhile.
Each push stamps its items inside its transaction by incrementing the
user's WriteRevision, so a reset committed during the push conflicts
with it and the retry gets the new generation. Items stored before this
change have no generation and count as generation 0.
* api: reject pushes that cross a reset
A push retried after a conflicting reset was stamped with the new
generation, although its items are still encrypted with the keys the
reset cleared. The push now keeps the generation it first saw across
retries and is rejected if a reset changed it.
Items are stamped through the captured replacements, so a lazily
enumerated input isn't left at generation 0.
Client errors thrown by a hub method now reach the client as hub
errors, since SignalR hides other exceptions' messages outside
development.
* api: reset under a lockout and clear token caches over RPC
Sessions are revoked while the user is locked out, retrying and then
aborting the reset if that fails. Hub connections, devices, inbox keys
and monographs from before a reset are fenced by the user's generation.
Identity now calls each server to clear cached tokens instead of
publishing a message, and the API and subscription server keep their
introspection cache in Redis so every replica sees the clear. Servers
without the call still get the message until they're upgraded.
Logins during a reset say so, and failed purges are counted for alerting.
* api: close the gaps the reset review found
- the old devices are purged one at a time in a transaction, so a device
registering again keeps the ids recorded for it
- the reset purge waits 15 minutes for requests still writing to the old
generation, then runs once
- republishing a monograph replaces a copy the purge hasn't removed yet
- inbox keys from before a reset no longer show or count toward the limit
- the reset holds a 10 minute lock through the attachments' removal, refuses
to overlap another reset, and keeps a lockout set while it ran
- the purge failure counter is exported from the first run
* api: only tag sync items with a generation
The user's monographs, inbox keys, inbox items and devices are few enough
to delete during the reset, before the generation changes, so only the
sync items need a generation and a background purge. UserPurgeJob now
deletes them itself, and the purge failure counter has no labels.
* api: reset in one transaction and keep devices that fetch across it unsynced
The generation bump, the user check and the deletes of monographs, inbox
keys, inbox items and devices run in one transaction, so a failed reset,
or one for a user without settings, leaves nothing deleted.
A fetch already under way when the reset commits no longer marks its
re-registered device as synced, so it still does a full sync after
logging in again.
* api: log out the other devices before resetting
They're told as soon as their sessions end, so their open sync
connections close before the reset rather than after it.
* api: log out the other devices after a password change even if their sessions weren't ended
* identity: keep ended sessions' cache keys until a clear succeeds
Ending sessions deletes them before their cached tokens are cleared, so
a retry after a failed clear found nothing to clear and succeeded while
the revoked tokens still worked from the cache.
* api: delete users in the background
Deleting a large account ran every collection's delete in one Mongo
transaction, which outlived Mongo's time limit and the request timeout.
The delete now marks the user's settings with DeletedAt and unregisters
the user from Identity, and UserPurgeJob purges the data after a grace
period, one idempotent step at a time, retrying until it's done. A user
that still exists in Identity is unmarked instead of purged.
A deleted user's open sync connections are cut off by a hub filter, which
also takes over the sync access check, and unregistering clears the
user's cached token introspection.
Identity drops delete_user and adds user_exists, so it must be deployed
before this API.
* api: simplify the background user deletion
* api: address review of the background user deletion
Covers uploads admitted by a cached token in the grace period, keeps a mark set by a retried delete, tests that open connections are cut off, and keeps delete_user for API instances that predate this change.
Re-check inactivity inside the transaction so a device that syncs in the
meantime keeps its ids, and scope the id deletion by user so another
user's device with the same id is left alone.
Identity already ran on driver 3.x through AspNetCore.Identity.Mongo 10.1.0 and Streetwriters.IdentityServer4.Contrib.MongoDB 5.0.0, while Streetwriters.Data and Streetwriters.Common were built against 2.30, so shared code could hit APIs removed in 3.0 at runtime in Identity only. Every project now uses 3.12.
- MongoDB.Driver.Core is part of MongoDB.Driver in 3.x
- AspNetCore.Identity.Mongo 10.1.0 in Common, matching Identity, which needs Microsoft.Extensions.DependencyInjection 9.0.2
- AspNetCore.HealthChecks.MongoDb 9.0.0, built against driver 3.x
- tests use EphemeralMongo 3.2, as EphemeralMongo8 2.0 is built against driver 2.x; it no longer stops mongod on exit, so the Identity tests now dispose their runner like the API tests do
Committing or discarding the keys of a password change that failed midway trusted the client to have just logged in. An older session could discard keys for a password that had been set, leaving them unwrappable. Both now require the token's auth_time to be after the keys were staged, and return login_required otherwise. Refreshed tokens keep the auth_time of the original login.
Discarding still waits until the password change can no longer be running.
The fetch filter compared pending monograph IDs with _id as strings, but _id is stored as an ObjectId, so monographs without an ItemId were only ever sent during a full sync. Valid IDs are now parsed into ObjectIds first, as MonographsController already does; malformed ones are only matched against ItemId.
DeleteDirectoryAsync sent every key in one DeleteObjects request, which S3 caps at 1000, and ignored keys S3 failed to delete. It now uses the same batching as DeleteObjectsAsync, and lists objects under "{userId}/" so the prefix can't match another user whose ID starts with the same characters.
Account deletion and reset delete attachments last, after the user's data is already gone, so a failure there is now logged instead of turning a completed deletion into an error.
Identity publishes ClearCache to a service's WAMP address, which reaches only one replica, so a revoked token stayed valid on the others for up to 30 minutes. With CACHE_REDIS_CONNECTION_STRING set, the replica that receives it publishes the keys on Redis and every replica removes them from its in-memory cache. The cache itself stays in memory so a Redis outage doesn't affect authentication; without Redis, only the receiving instance is cleared, as before.
MinioFixture starts a MinIO-compatible server in Docker with Testcontainers (Silo, since MinIO no longer publishes images) and points S3Clients at it. S3ServiceTests cover signed uploads and object sizes, deleting an object and a user's directory, and multipart uploads within and past the storage limit. The interface stub moves out of ApiErrorResponseTests so both can use it. Running the tests now needs Docker.
Fetches and pushes with a null or empty device ID were accepted: a fetch registered a device with no ID, which every such request from that user then shared. Both now fail with a HubException before anything is registered or written.
Self-hosted and new deployments got none of the API's indexes, and without unique ones concurrent upserts can duplicate sync items. A background service creates any missing index in the notesnook database, including unique UserId + ItemId on sync collections and unique sync_devices and user_settings keys. Existing indexes are never changed: one with the same name but a different definition is logged. Each index is created on its own, so existing duplicates only skip that index, and no failure stops the host.
Registering a device inserted a new document every time, so concurrent registrations (two first fetches at once) left duplicate devices, and one stuck with IsSyncReset=true full-synced on every fetch. Registration is now an upsert on UserId + DeviceId; registering an existing device resets it to a full sync.
Signup ignores a duplicate-key error when inserting user settings: until Identity's users are unique, a double-submitted signup can resolve to the same user twice.
Controllers no longer catch everything and return ex.Message as a 400, which leaked internal messages and made outages look like client errors. User-facing errors are now ClientExceptions; everything else is a generic 500 or a 503. S3 failover throws S3StorageUnavailableException when every endpoint fails transiently.
Deleting an account checks the password first, since Identity's "Wrong password." only arrived as a WAMP runtime error. Inbox API key checks no longer turn database errors into 401s. Monograph sanitization fails closed instead of storing unsanitized content, and an unreachable WebRisk counts as safe, like an error response already did.
The hub's two fetch lists, its push map, the encryption verifier lookup and the account delete/reset lists each named every collection. They now all come from SyncItemCollections on the repository accessor, which also marks the legacy settings collection as deleted but not synced. A test checks every repository is registered.
The quota was checked, then the file uploaded, then usage incremented, so concurrent uploads could exceed it. Reserve the size with a conditional increment before uploading and release it if the upload fails. Also only roll over the usage that was read in GET /users, and make Limit.Value a plain property so setting it doesn't change UpdatedAt.
Publishing now waits at most 10s for a connection. Opening the channel
is guarded by a lock so concurrent callers share one connection, and
disconnect handlers are attached once per channel so they no longer
multiply on every reconnect.
Abdullah Atta