GL_INVALID_OPERATION from draw call: glGetError returns it once, then GL_NO_ERROR — which command actually failed?

An OpenGL 4.5 core-profile application (desktop, GLFW-created context) renders a scene with several draw calls, VAOs, and shader programs per frame. After a recent change, nothing appears on screen. Polling glGetError once per frame reports GL_INVALID_OPERATION a single time, then returns GL_NO_ERROR on every subsequent call, even though the failure persists visually.

The documentation describes error flags as sticky until queried, with one flag returned and cleared per call, and GL_INVALID_OPERATION covering many distinct state problems: drawing with an incomplete framebuffer, using a program that failed to link, or drawing without a bound VAO in a core context. That makes a single polled value ambiguous — it is unclear which command raised the flag, or whether multiple independent errors were queued and only the first was observed.

A debug context with glDebugMessageCallback is available as an option, but message presence and content are documented as implementation-dependent, so it is not clear how much to trust it across NVIDIA, AMD, and Mesa drivers.

Is a single glGetError result sufficient to conclude only one error occurred, or must the call be looped until GL_NO_ERROR to drain all pending flags?

What is the documented way to attribute GL_INVALID_OPERATION to the exact failing command rather than the frame in which it was polled?

Should GL_COMPILE_STATUS/GL_LINK_STATUS and glCheckFramebufferStatus be ruled out first, given they fail silently without setting a glGetError-visible draw-time fault?