Commit 63a2849
authored
Emit error log if deregistered search attribute in chasm vis task (#8715)
## What changed?
Emit error log if deregistered search attribute in chasm vis task.
Original thread:
#8662 (comment)
## Current State
If user deregisters search attributes while the task is getting
processed, current code leads to task failure.
In ES, if the search attribute has been deregistered, upsert SA task
execution would still fail when generating the ES Doc and attempting to
decode the value.
In the SQL implementation, since these fields are constant and always
attached to the NameTypeMap/ClusterMetadata, Upserting these fields
would succeed, so there is a discrepancy between these stores.
## Why?
Once we have parity between ES and SQL for preallocated columns, we
should not throw an error if a search attribute gets deregistered when
executing the CHASM vis task and just do a best effort upsert call. User
deregistering search attributes after archetype execution is a valid use
case.
A valid concern is if the visibility component somehow has an incorrect
search attribute (eg. field name). There was an issue the past caught
because errors were thrown during translation, which showed search
attribute already translated to field name before hitting the
translation layer (due to application code bug). However, Error logs
should be sufficient to debug.
## How did you test it?
- [X] built
- [X] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)1 parent b096c97 commit 63a2849
1 file changed
+5
-1
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
13 | 13 | | |
14 | 14 | | |
15 | 15 | | |
| 16 | + | |
16 | 17 | | |
17 | 18 | | |
18 | 19 | | |
| |||
409 | 410 | | |
410 | 411 | | |
411 | 412 | | |
412 | | - | |
| 413 | + | |
| 414 | + | |
| 415 | + | |
| 416 | + | |
413 | 417 | | |
414 | 418 | | |
415 | 419 | | |
| |||
0 commit comments