If a key is undecryptable, rename it, log it, regnerate it

[ahmelsayed]

The runtime today fails with 500 when keys are not decryptable and the user needs to manually go and clean them up.

It'll be much better if for example

1. rename <name>.json to <name>.json.undecryptable
2. log message saying that happened.
3. create a new key

[paulbatum]

Chat with @fabiocav to get more specifics on how this should work.

[ahmelsayed]

and btw, this is just my proposal for how things could be. There are other options that I remember @fabiocav suggesting as well; for example write more metadata into the secrets that would tell you what happened.

Regardless, the only way to get out of this situation currently is manual (delete all secrets in your storage account or in your file system depending on what an app setting says), and there should be a better way.

[ericleigh007]

Can you explain exactly the workaround you mentioned above? I'm in this situation and don't really want to recreate the function app.
"Regardless, the only way to get out of this situation currently is manual (delete all secrets in your storage account or in your file system depending on what an app setting says)"

-thanks
-e

[paulbatum]

@ericleigh007 Try this:

1. Go to https://.scm.azurewebsites.net/DebugConsole
2. Go into data -> functions
3. Delete the secrets folder

If that doesn't work:

1. browse to the storage account for your function app into the azure portal,
2. go into containers -> azure-webjobs-secrets
3. delete the container with your function app name e.g. the circled entry in this screenshot:
   

[fabiocav]

Had a quick chat with @alrod and we'll start this simple by following an approach similar to what @ahmelsayed suggested:

If we are unable to decrypt the payload:

1. Rename the file to <name>-<timestamp>.undecryptable.json (name would be the same as the original file, as this could happen to the host or function secrets
2. Log a message with the details
3. Create the new key

NOTE: We may need to specially consider scenarios where multiple sites are mistakenly setup with the same share, as this may lead to a situation where the sites keep correcting each other's secrets, initiating a loop. So we may need to limit the number of times we take this action.