Skip to main content
Solved

InternalException on Data Push Job after Athena SQL Editor extraction (large volume)

  • September 16, 2026
  • 1 reply
  • 7 views
michael.hamme13
Level 4
Forum|alt.badge.img+6

Hitting a wall with an extraction of tens of millions of rows from Amazon Athena via the SQL editor. The pull itself seems to finish without complaint, but the pipeline then breaks at the Data Push Job step with an InternalException.

A couple of things I've noticed:

  • A similar extraction through the visual editor (same columns, but a much smaller row count) runs without any issue as part of the daily load, so I don't think it's the source system itself causing this.
  • I only moved to the SQL editor because I needed JOIN and CAST logic that the visual editor doesn't support.
  • Not sure yet whether it's the volume or the JOIN/CAST operations that's actually the trigger.

Has anyone hit Data Push failures at this scale, or specifically with JOIN/CAST in SQL editor extractions? Any insight into what usually causes this would help.

Best answer by yingtao.gu13

Before assuming it's purely a volume problem, it might be worth going back through the extraction code line by line. A couple of small things tend to cause exactly this kind of failure: stray empty lines sitting between statements in the SQL editor, which can throw off parsing, and duplicate columns that sneak in once JOINs are added, which the table creation step downstream doesn't always handle gracefully.

Neither is guaranteed to be the cause here, but both are quick enough to check before treating the row count itself as the culprit.

      1 reply

      yingtao.gu13
      Level 7
      Forum|alt.badge.img+11
      • yingtao.gu13
      • Level 7
      • Answer
      • September 16, 2026

      Before assuming it's purely a volume problem, it might be worth going back through the extraction code line by line. A couple of small things tend to cause exactly this kind of failure: stray empty lines sitting between statements in the SQL editor, which can throw off parsing, and duplicate columns that sneak in once JOINs are added, which the table creation step downstream doesn't always handle gracefully.

      Neither is guaranteed to be the cause here, but both are quick enough to check before treating the row count itself as the culprit.

      Help companies to achieve digital process excellence
      Community Code of ConductAccessibility statement