Closed kcullion closed 3 years ago
@joneubank Before I close this i would like to get to the root of this problem. Can you please record what happened on this ticket when you figure it out?
Can confirm that the index wasnt ever changed, it has always had the new release_state
/embargo_stage
properties in the mapping, replacing the release_stage
property from release_2.0 index.
However, the platform-api had not been restarted after the new indices were aliased. @blabadi confirmed that the platform-api was restarted in both staging and prod within the last 24 hours. When restarted, the arranger GQL schema is regenerated from the index mapping.
When the arranger schema updated, the old prop was removed. The UI was requesting this property when fetching the facets, even though the UI was never using the data returned for this property. The result was no facets showing.
The fix was to remove the reference to the release_stage
property in the facet data request.
Going forward we need to restart the API after deploying an index with a new mapping. Alternately, we need a way to regenerate the arranger schema without a restart (this may be doable in arranger but I haven't looked for this in some time). By doing this in lower environments we can confirm if there are discrepancies between the UI GQL requests and the generated API, thus preventing issues resulting from updating the mapping in prod.
@joneubank do we know why prod api was restarted?
No, but there are lots of potential reasons. It's not recorded who initiates restart. Might've just been by kubernetes managing resources even.
Describe the bug
Please fix the facet panel in production and report on why this problem is happening