Steps Interface Join Returns No Data Despite Valid Keys - Works in Custom SQL

Issue Summary:

I’m encountering an unexpected behavior in Quick’s new Steps interface where a join between two tables returns no data, even though the same join logic works perfectly when implemented as custom SQL within a single node.

Setup Details:

  • Data Source Type: Redshift

  • Steps Configuration:

    1. Creating two source tables (let’s call them Table A and Table B)

    2. Attempting to join Table B to Table A

The Problem: When I configure the join through the Steps interface:

  • Join type: Inner

  • Join key from Table A: acme_id

  • Join key from Table B: acme_id

  • Result: The query executes successfully but returns 0 rows

What DOES Work:

When I bypass the Steps approach and write the equivalent logic as custom SQL in a single node, joining the same two tables on the identical field, the query returns the expected data without any issues.

sql

-- Example of working custom SQL pattern
SELECT *
FROM table_a a
JOIN table_b b ON a.key = b.key

What I’ve Verified:

  • ✓ Join keys contain matching values in both tables

  • ✓ No data type mismatches between join fields

  • ✓ No NULL values in join keys

  • ✓ The custom SQL version confirms the data relationship exists

  • ✓ Transformations can be applied to Table A and complete successfully up to the join step

Questions:

  1. Has anyone else experienced joins failing in the Steps interface while working in custom SQL?

  2. Are there known limitations or specific requirements for joins in the Steps workflow that differ from standard SQL?

  3. Could this be related to how Quick handles the transformation pipeline before the join operation?

Additional Context:

This seems like a straightforward join operation.

Any insights or workarounds would be greatly appreciated!

Hi @Dave_LeBlanc,
Thank you for bringing this to attention; I know that there are still some features being worked on for future implementation; all feedback towards the new experience is welcomed as so that it can be taken into consideration. I’ll loop in @vignessh.b so that he can get eyes on this as well.

1 Like

@Dave_LeBlanc (cc: @Brett ) Here is one reason I can think of. We have an Inner Join here. The Preview randomly samples 1,000 rows from the Step. We then perform transformations on top of it. So it is possible that the randomly sampled values between the two tables are not matching. So table 1 could have states Washington, Texas, Oregon vs Table 2 having Georgia, California in Preview and the Inner Join is not returning the Preview result.

When you do the SPICE refresh (full data ingestion), it will give full results. Can you do a Save & Publish and confirm?

If this does not work, please let us know.

Reason why SQL works is because the query is run first and then the Preview gets applied.

Hi @Dave_LeBlanc,
Following up here as it’s been awhile since last communication took place on this thread; were you able to review the most recent reply and if so, did this help with your case?

If we do not hear back within the next 3 business days, I’ll close out this topic.

Thank you

Hi @Dave_LeBlanc,
Since we have not heard back further, I’ll go ahead and close out this topic. However, if you have any additional questions, feel free to create a new post in the community.

Thank you