Taken at face value:
- Prior to April 30,
storage:appcould be rolled out usingbulk upgrade - A change was made, which Atlassian confirms is being treated “as a bug”
- The changelog entry mentions "Atlassian is actively investigating restoring
storage:appas a scope increase that is able to be managed bybulk upgrade - ECO-1493 mentions similar
I may be misunderstanding or underestimating the restoration work required, but isn’t this just reversing the April 30 change?
I don’t understand why ECO-1493 created 5 days ago is still in “Needs Triage” status.
You’ve indicated that this was an unintentional change to something that previously worked. What “active investigation” is needed? Presumably you know the cause and you know the previous state you want to get back to.
Here’s why this matters to us:
- We enjoyed the benefit of the prior-April 30 behaviour to bulk upgrade one of our apps
- However, as we’ve noted previously, running
bulk upgradeoften leaves a number of installations as “failed”. In the case of this app, we have approximately 30 installs that failed to be upgraded successfully. - Of those 30 failed installs, we still see traffic from some to our old Connect infrastructure, meaning that we’re left maintaining this infrastructure (at a cost) for these stragglers.
- When we try to re-run the bulk upgrade again for these installations, we now get “No upgrade paths available”, presumably due to
storage:appnow no longer being eligible
So we’re now in this limbo state where most of our installations were upgraded with storage:app, but for the remainder we’re waiting for ECO-1493 to be resolved.
If we’re to believe that this was genuinely a bug that wasn’t supposed to change previous behaviour, surely that should have been fixed by now.