Variables intermittently not being replaced in runbook runs

Hi !

We are experiencing some weird new problems with variables sometimes not being properly replaced during runbook runs.

A few facts:

  • We are running the latest and greatest version 2021.2 (Build 7428)
  • We do have 3 workers running
  • We do have 2 spaces. The project in question was created when there was only 1 space.
  • The part of the variable not being properly replaced stems from a variable template in a variable set.
  • The runbook run ist tenanted.
  • The Runbook run is meant to be trigger by a scheduled trigger every couple of minutes
  • Most of the time when the runbook run was triggered by a scheduled trigger, the variable replacement fails. But sometimes it does work.
  • Most of the time when a failed runbook run is triggered again by a human (via ‘try again’), the variable replacement does work and the runbook runs to completion successfully. But sometime it doesn’t.

We are not sure when the problem started. It could have emerged this morning after the update to version 2021.2 (Build 7428), but we have no proof.

We don’t know how to tackle this one. Please help.

Thanks! David

Hey David,

Thanks for reaching out and for all of the information.

We do have another somewhat similar report from earlier today but it is based on Tenant variables: https://github.com/OctopusDeploy/Issues/issues/7042. That’s not necessarily saying it’s exclusive to them, that is just what we were able to reproduce as that’s what the first case was reporting an issue with.

I assume you meant “isn’t” here?

Can you please tell me where the problem variable resides(just confirming the variable is in a library variable set and attached to the project), how it is scoped, and how it’s used within the process? Please let me know if there’s anything else that differs with the linked issue and what you’re experiencing. If you’d like to send me screenshots of everything in a DM, that would be likely help our reproduction efforts.

Looking forward to hearing back.

Best,
Jeremy