Open BenLubar opened 4 years ago
An error returned from any database method will result in go-fed code aborting processing, and will return the underlying error back up to the calling code. I think a reasonable implementation of Lock
would be to await for the lock to be available or for the context to expire (for example, due to a deadline-exceeded type of error), and if it is the latter then returning an error. This will let your calling code send a proper HTTP code back to the client.
Since Lock
is called for many different kinds of processing though, it is possible for things to only become partially processed. go-fed
relies on the interface implementations to support idempotency, so if a caller retries w/ the same payload the processing (ex: "creating an activity in the db") and side effects (ex: "send notification to a user") only happens once.
Does go-fed expect pub.Database.Lock to keep trying until the context expires, or should pub.Database.Lock immediately return an error if the lock is already held on a URL?