Hi GoodData Support. A customer of ours has received an empty attachment for a scheduled export on Monday this week. This is a weekly scheduled delivery that has been running since November 2025; this not the first time the customer has received an empty attachment. The email delivered without error and the automationResult for the export has SUCCESS status, but the Excel and CSV attachments have no data other than headers. The associated dashboard has one visualization - a table. The traceId for the automationResult is

93f0b9ca-a42b-4ab4-b690-f4310cd8aa59

. Could someone please investigate why the attachment was empty for this scheduled export? Happy to provide further details via DM.

Thinking completed I am sorry, but the provided knowledge sources do not contain internal log details for traceId

93f0b9ca-a42b-4ab4-b690-f4310cd8aa59

, so I cannot confirm the exact reason why the file generated with only headers for this specific run. Based on similar documented cases: • When an export succeeds or delivers but contains only headers or no data, the visualization typically returned no rows at the time of execution because no data matched the active filters or conditions [Slack forum user question]. • If your data refresh overlaps with the scheduled execution time, or if the underlying data was temporarily unavailable or filtered out, the export engine will process the table as empty [Slack forum user question]. Resolving the specifics requires a GoodData Support team member to inspect the backend logs and execution trace. The Support team monitors this Slack community and will step into the thread as needed. To help the Support team investigate, please add the following details directly to this thread: • Organization ID and Workspace ID • Dashboard ID and Visualization/Insight ID • The schedule definition (cron timing, timezone, and execution user) • The traceId (

93f0b9ca-a42b-4ab4-b690-f4310cd8aa59

) • Whether manual export of the visualization currently yields data under the same filter context and for the user owning the schedule Support Options Community support (Startup & Professional) You are already in the right place. The GoodData Support team monitors this Slack, and a team member will join the conversation when human review is needed. Please keep the discussion and post the requested details directly in this thread. You can also consult the Community Forums. 24/7 Support (Enterprise plans) If you are on an Enterprise plan or experiencing a Severity 1 (L1) critical issue, these direct options are available in addition to this thread: • Submit a ticket • Email: support@gooddata.com • Phone: +1 (415) 200-0194 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups. 👀 Our Support team monitors all messages and will jump in if needed.

Hi Eoghan, we’ve checked the logs for this automation. The Monday 11:00 UTC run completed and was delivered successfully. The table’s query ran live against your data source and returned 0 rows, so the files were generated correctly but only had headers. In the same run, the

process_name

filter also found no matching values. This means no data matched the filters when the schedule ran. Could you check: 1. Does a manual export return data when run as the schedule owner, with the same filters? 2. Do the

process_name

values in the filter still exist in the data? 3. Does your data load run around Monday 11:00 UTC? Also, could you share the dates of the earlier empty deliveries? We’ll check whether they follow the same pattern.

Hi @Michael Ullock, thanks for the update. The live run against our data source makes sense, given when the previous data sync ran. In response to your questions: 1. I believe manual export runs for the customer/user, but I'll ask if they can confirm; it definitely works for me but I have admin privileges so no UDFs get applied 2. Yes the

process_name

filter value still exists in the data 3. Our data load ran at 10:03 and then again at 11:03 - so there should have been no conflict when the schedule query ran, i.e. data would not have been actively refreshing then, tables should have been populated The earlier empty deliveries are historical and I don't know if even the customer has the emails; I mentioned this to highlight its not the first time they've experienced this (although could be for the user in question). Are you able to share the query run by the scheduler? It's unusual that the results from live data source query were empty, and the specifics of the executed query could help figure out what happened. Now that subsequent data loads have run, it's difficult to say if any of the source tables were empty; they certainly shouldn't have been. But the data load prior to schedule run did update one of the tables that has fields from the query, and that is implemented as a truncate+refill, so it could be a synchronization bug on our side.

Thanks Eoghan, that’s helpful. Our logs don’t record the generated SQL, but your warehouse query history will have it: look for queries from the GoodData data source user at 110013–14 UTC on 28 Sep. There are two (one for the CSV, one for the XLSX), and both returned 0 rows. Two things worth checking: 1. The export ran as the recipient user, not as an admin, so any user data filters on that user were applied. Could you check whether that user has a UDF that might exclude everything, for example on

process_name

or a related attribute? The SQL in your query history will show the UDF conditions too. 2. On the truncate+refill: how long did the 10:03 load take, and do the truncate and refill run in one transaction? If the refill was still running or not yet committed at 11:00, that would explain an empty result.

Thanks for the suggestion Michael I'll see if we can fish the query out of our db logs. To your other points: 1. All our GoodData users have a UDF, which checks for their Midaxo user_id against various lookup tables. This is fixed for each user and certainly hasn't changed recently, but I will check how it gets applied in the query 2. The 10:03 load took 7 seconds, so the data should definitely have been ready for read

Thanks Eoghan, that helps narrow it down. A 7-second load rules out timing, so my thinking is the UDF is now the most likely cause. Your UDF is fixed per user, but it filters through lookup tables, so it depends on what those tables contain at the moment the query runs. If the lookup rows for that user were missing at 11:00, the UDF would filter out everything and both queries would return 0 rows, which is what we saw. When you find the SQL, does the UDF part (the join or condition on that user’s user_id) please let us know if this explains the 0 rows

Hi again Michael. I figured out the problem on this one. The scheduled export definition has a stale value for the

process_name

- when you asked about it, I didn't think to check the definition to compare the value to the live filter. The value was changed upstream (i.e. by the customer in our product) on the 8th of May, so presumably the schedule query executions every Monday have been delivering empty results since then. It's unclear if the customer mentioned this to our own Customer Support team earlier than this week. I'm going to recreate the schedule on behalf of the customer and ensure it uses live values. Thanks for your help on this one, really appreciate it!