fix: update the auto-complete API reading logic

[ahmadshaheer]

Summary

Related Issues / PR's

Screenshots

NA

Affected Areas and Manually Tested Areas

---

Important

Updates auto-complete API logic by mapping data types to attribute values, affecting result processing in multiple files.

• Behavior:
  • Introduces DATA_TYPE_VS_ATTRIBUTE_VALUES_KEY in queryBuilder.ts to map DataTypes to IAttributeValuesResponse keys.
  • Updates useFetchKeysAndValues in useFetchKeysAndValues.ts to use the new mapping for setting results based on data type.
  • Modifies useGetAllConfigOptions in useGetAllConfigOptions.ts to directly use stringAttributeValues.
  • Updates useGetAggregateValues in filterUtils.ts to use the new mapping for setting results based on data type.
• Functions:
  • Adds isAttributeValuesResponse function in useFetchKeysAndValues.ts to check payload structure.
• Misc:
  • Minor refactoring in useGetAllConfigOptions.ts and filterUtils.ts to align with new logic.

^{This description was created by for cc2fa31. It will automatically update as commits are pushed.}

[ellipsis-dev]

❌ Changes requested. Reviewed everything up to 5770e9d in 2 minutes and 51 seconds

More details

• Looked at 116 lines of code in 4 files
• Skipped 0 files when reviewing.
• Skipped posting 7 drafted comments based on config settings.

1. frontend/src/constants/queryBuilder.ts:422

• Draft comment:
  Good use of a mapping constant. Ensure consistency by using design tokens if applicable.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50%
  None

2. frontend/src/pages/MessagingQueues/MQGraph/useGetAllConfigOptions.ts:37

• Draft comment:
  Consider using the DATA_TYPE_VS_ATTRIBUTE_VALUES_KEY mapping instead of Object.values to improve clarity and consistency.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

3. frontend/src/pages/TracesExplorer/Filter/filterUtils.ts:331

• Draft comment:
  Good update using DATA_TYPE_VS_ATTRIBUTE_VALUES_KEY; ensure the cast on keyData.dataType is safe.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

4. frontend/src/hooks/queryBuilder/useFetchKeysAndValues.ts:240

• Draft comment:
  The specific setResults call using DATA_TYPE_VS_ATTRIBUTE_VALUES_KEY is immediately overwritten by a generic setResults call. Use an else clause so the specialized results aren’t lost.
• Reason this comment was not posted:
  Marked as duplicate.

5. frontend/src/pages/MessagingQueues/MQGraph/useGetAllConfigOptions.ts:37

• Draft comment:
  Using a hardcoded 'stringAttributeValues' here; ensure this is intentional. For consistency, consider using the DATA_TYPE_VS_ATTRIBUTE_VALUES_KEY mapping if multiple data types are supported.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

6. frontend/src/pages/TracesExplorer/Filter/filterUtils.ts:332

• Draft comment:
  Casting keyData.dataType as Partial may hide potential type issues if keyData.dataType is missing or unexpected. Ensure it’s always valid before using the mapping.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  The comment suggests there could be type issues, but examining the code shows keyData.dataType is already strictly typed through the traceFilterKeys const object. The cast seems unnecessary but not harmful. The comment is speculative about potential issues rather than pointing out a concrete problem.
  I could be wrong about the type safety - there might be places where traceFilterKeys is modified at runtime. The DataTypes enum might be extended elsewhere.
  The traceFilterKeys is defined as a const object with explicit types, and TypeScript would catch any type mismatches at compile time. Runtime modifications would be caught by TypeScript's type system.
  The comment should be deleted as it's speculative about potential issues rather than identifying a concrete problem, and the existing type system already provides the safety being discussed.

7. frontend/src/pages/TracesExplorer/Filter/filterUtils.ts:346

• Draft comment:
  Calling setFetching during render (in the if(!value) branch) is a side effect. Move this logic into a useEffect to avoid state updates during render.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

Workflow ID: wflow_8cC8wXTKjrCW4fqV

---

Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

Duplicate setResults call: the conditional branch sets results and then it's immediately overwritten. Consider using if/else to avoid overriding the value.

[ellipsis-dev]

👍 Looks good to me! Incremental review on cc2fa31 in 1 minute and 8 seconds

More details

• Looked at 12 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 2 drafted comments based on config settings.

1. frontend/src/hooks/queryBuilder/useFetchKeysAndValues.ts:245

• Draft comment:
  Adding the early return after setting results prevents the fallback logic from running. This ensures that when payload is recognized as an attribute value response, the state is updated only once.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
  This comment is purely informative, explaining the effect of an early return in the code. It doesn't suggest any changes or ask for confirmation of intent, which violates the rules.

2. frontend/src/hooks/queryBuilder/useFetchKeysAndValues.ts:245

• Draft comment:
  Early return here prevents the fallback logic from running when the payload matches the expected IAttributeValuesResponse structure. Consider adding an inline comment to clarify why this early exit is necessary.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  The early return's purpose is fairly clear from the context - it's part of a type-specific handling branch. The code is already well-structured with the isAttributeValuesResponse type guard. Adding a comment here would be stating the obvious. The logic flow is straightforward enough that a developer can understand it without additional documentation.
  I could be underestimating the complexity for future maintainers. Some developers might find the dual-path logic confusing without explicit documentation.
  The code structure itself documents the intent - there's a clear type check and type-specific handling followed by fallback logic. Additional comments would be redundant.
  This comment should be deleted as it requests documentation for something that is already clear from the code structure and context.

Workflow ID: wflow_brH6YuQzraJzH3Ev

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[srikanthccv]

@ahmadshaheer we should get rid of this generic Object.values(payload) and handle it for different responses types (not just for IAttributeValuesResponse) by accessing the object keys instead.

[srikanthccv]

@ahmadshaheer not handled here

signoz/frontend/src/components/CeleryTask/CeleryTaskConfigOptions/useGetCeleryFilters.ts

Line 71 in 239ea9d

({ payload }) => Object.values(payload || {}).find((el) => !!el) || [],

signoz/frontend/src/components/QuickFilters/FilterRenderers/Checkbox/Checkbox.tsx

Lines 79 to 84 in 239ea9d

	const attributeValues: string[] = useMemo(
	() =>
	((Object.values(data?.payload || {}).find((el) => !!el) ||
	[]) as string[]).filter((val) => !isEmpty(val)),
	[data?.payload],
	);

Is there a better way to identify where IAttributeValuesResponse is used in codebase? I was trying with global search on Object.values(