I'm not sure this was your intention, but you have just described how folks are supposed to do postmortem and retrospectives at most agile shops, as well as how Toyota created the kanban process and implemented the andon cord. It's strange and probably not useful if it's based around assigning guilt. But if it's based around trying to uncover a root cause in process or system deficiency and solving that, then no, it doesn't seem strange to me.

You can modify your code to use the API correctly, but if your team doesn't get the documentation fixed or the test environment to sync back up with the production API, your team is not solving the issue.

Your code can cause headache for everyone after runs in production for a month, but unless your team begins to do code review, you're not solving the issue.

In a very literal sense, the idea of the team finding an issue and resolving it (apology or not) is extremely important and one of the few ways for an organization to improve rather than decay over time. The apology is almost a formality.