1235383 - secrets API won't re-create an expired secret

Status: RESOLVED FIXED

(Taskcluster :: Services, defect)

Description

[Dustin J. Mitchell [:dustin] (he/him)]

I'm getting 410's trying to read garbage/dustin/foo, but 409's trying to set.  Update seems to work.

So, maybe the better way to phrase this is: there's no good reason to distinguish update and set in this API.

Comment 1

[Dustin J. Mitchell [:dustin] (he/him)]

Attachment: https://github.com/taskcluster/taskcluster-secrets/pull/12

Comment 2

[John Ford [:jhford] CET/CEST Berlin Time]

Comment on attachment 8714572 [details] [review]
https://github.com/taskcluster/taskcluster-secrets/pull/12

Took a look at this and I think there's a couple of open questions.  Please set the flag back to ? when I should take another look

Comment 3

[Dustin J. Mitchell [:dustin] (he/him)]

Comment on attachment 8714572 [details] [review]
https://github.com/taskcluster/taskcluster-secrets/pull/12

On the basis of the "good to go" comment, I merged PR 11 but not this one, only to realize all of your concerns were about the commits in PR 11, except the race condition.  I don't think that's an issue here.  Care to have another look?

Comment 4

[Dustin J. Mitchell [:dustin] (he/him)]

deployed

Comment 5

[John Ford [:jhford] CET/CEST Berlin Time]

Sorry, didn't see the review flag.  If you don't mind, the issues that I raised would still be good to fix.

Comment 6

[Dustin J. Mitchell [:dustin] (he/him)]

I'm not too worried about the race.  It would come if the set API call occurred at exactly the time the expiration utility deleted the old entity (which is some time *after* its expires timestamp).  In that case, the user will get an error and the client will retry.

That was the only issue I didn't address.

Comment 7

[John Ford [:jhford] CET/CEST Berlin Time]

oh!  yah, the race doesn't concern me too much.  it was the other things, so if those are addressed, great!