Hi, I'm experiencing an issue with the "Write to Email Waterfall." The tables for today and yesterday are showing blank cells. When I manually update the table, the cells populate and are sent to the email waterfall. However, if I don’t re-run the update, the data doesn’t proceed to the next step. Could you please help resolve this issue?
It seems you're experiencing an issue with our "write to table" feature for your email waterfall. This problem can occur when the data isn't processing correctly. Here's how you can resolve it: 1. Use the Force Run option in your table settings. This might take some time depending on your table size. 2. If the issue persists: • Delete the affected columns • Create fresh columns • Re-map your data to the write-to-other table • Ensure auto-update is activated These steps should help resolve the blank cells issue and ensure your data flows correctly to the email waterfall. If you need further assistance, please request human support by clicking on "Talk to a person".
https://app.clay.com/workspaces/12893/workbooks/wb_mrFzQHsUHT8P/tables/t_FVXKTfXy9ojh/views/gv_j589yWrjUWx6 Here is the link of the table. I would really like to avoid re-running all of the tables manually 🙂
Thanks! We've reopened this thread. You can continue to add more detail directly in this thread.
Hey, we re-run all of the tables after the bug has been resolved, and yesterday they were running constantly. The issue I noticed with these tables is that not all of the rows run properly. Is it possible to get some of the credits back? https://app.clay.com/workspaces/12893/workbooks/wb_M9nBvGTq9jg7 https://app.clay.com/workspaces/12893/workbooks/wb_KdniVymo4Whj https://app.clay.com/workspaces/12893/workbooks/wb_rKQ2XaGuYqeo/tables/t_UnW7Zxp4WzSX/views/gv_jkYzZWDhTwuv https://app.clay.com/workspaces/12893/workbooks/wb_SxK8xA5A5GVH/tables/t_Pabh5Uwsm4Vk/views/gv_KiXBDkipEWWS https://app.clay.com/workspaces/12893/workbooks/wb_htECPQgas4uM https://app.clay.com/workspaces/12893/workbooks/wb_AoD7vUxE2oBB/tables/t_paXeXjz95Ahg/views/gv_XNTnouJ8uc9u https://app.clay.com/workspaces/12893/workbooks/wb_eKjTwyMyRnVC/tables/t_x844CNzJEQvz/views/gv_XrqBn2gVuHWp
For context, I saw that Full Enrich is stuck on awaiting call back in one table, which appears to have taken credits, then to be refunded if not found.
here is an example table getting stuck of awaiting callback on Full Enrich column https://app.clay.com/workspaces/12893/workbooks/wb_35XPsoxWo5e5/tables/t_4KiCZPzFE6ru/views/gv_HmEeBZm3RGdj
Hi there Teodora. "Awaiting callback..." is a normal message for services like FullEnrich (and Wiza, SureConnect, IcyPeas, and some others). When FullEnrich completes their work, they send the result back to Clay. Clay is awaiting their call.
Behind the scenes, the last message from FullEnrich to Clay: LBKS✅ Email is being found. It will be posted to your callback URL once generated.LBKS
Our other users are reporting reduced general performance on several things in our workspace currently - Things like:
Full Enrich Columns getting stuck on awaiting call back and taking credits whilst stuck in this status for prolonged period.
Lookups running slowly.
Open AI not running at all with no run conditions and settings correct
Open AI columns running significantly slower. (we have credit, running on highest tier)
AI Enrichment breaking when using 'take action on this list' -> Ask AI
No processing status update showing when columns set to run.
appears columns are running then they just stop with no error message and no run logic to prevent them, input variables are fine.
Will try to get some examples as they come up
In the table shared earlier (https://app.clay.com/workspaces/12893/workbooks/wb_35XPsoxWo5e5/tables/t_4KiCZPzFE6ru/views/gv_HmEeBZm3RGdj), the logs I see show the requests starting ~8hrs ago. 24hrs is very long, though. I'm seeing 212 credits for the 106 successful FullEnrich results so far. I retried one (row 48) and it completed within a few seconds, which is more like the experience I would hope for. I'd recommend retrying, and seeing if those complete, as it seems FullEnrich did not report back on the last attempt. Definitey interested in specific examples of the other items you bulletpointed. We raised a couple issues on our status page this morning that sound related: https://status.clay.com/
yeah the 8 tables above all facing this issue with full enrich. will try re -running,
will keep an eye and drop any other buggy things here as they come up
from the original run?
as they appear to have been charged when looking at the credit usage view
https://app.clay.com/workspaces/12893/workbooks/wb_M9nBvGTq9jg7/tables/t_xqtDBMmo7UJZ/views/gv_YyrKfcN2yrgX also re runs appear to be queing when clicking single cells but not when running column
just filtered to awaiting call back and fore runned it and its now working
Hey, Just a heads-up—“awaiting callback” isn’t an error. That’s expected behavior for certain providers. We send the request and wait for them to respond through our callback system, which is built intentionally to handle these delays. As for the slow runs, that usually depends on the size of the table and the provider itself, as Mark mentioned. Re-running rows will trigger new enrichments and may use additional credits, so just keep that in mind when retrying. Let us know if anything else seems off!
Mark L. Bo (. - I think it's clear that there is an issue, as the cells that are saying awaiting call back have been in that status for a really long time, when clicked to run, they run straight away and return. I don't see how this is normal behaviour or why we should pay twice for the credits if we didn't get a normal execution the first time?
Hey, thanks for flagging this — that definitely doesn’t sound like expected behavior. Quick question: before you noticed the issue, did you happen to click “Stop Run” in the table? We’ve seen cases where doing that causes cells to get stuck in the “Awaiting Callback” state (since they're stopped).
Still, happy to take a closer look and make it right if credits were charged incorrectly. Let us know!
It is possible for some of the tables, but not for all of them
these tables were re-run due to the initial bug
Got it — can you let us know which tables weren’t affected by a manual “Stop Run”? That’ll help us narrow it down.
honestly i am not sure, we run many tables on a daily basis, and that day was chaotic 🙂
Please check what happens here, I am not sure if I should re-run the table or not https://app.clay.com/workspaces/12893/workbooks/wb_462VudJHRV6i/tables/t_cr7b7ka8dTdT/views/gv_Y8vGHSaUGxq5
Ignore
.
Bo (. Can we please have an update this issue. 8.5k credits have been lost today and many more from tables processed last week. We are nearly out of credits and have had to pause all data processing until this is fixed. The tool that is causing the issue is - FullEnrich
Sorry for spamming (long Monday)
Hey Daniel K. - Are you able to support here please? We're nearly out of credits and are unable to use Clay tables until the issue is fixed
Hey, I just checked your table and tried rerunning it—it is now processing correctly. The issue seems to have been caused by a “Stop Run” event that interrupted it earlier. You mentioned losing 10k credits—could you clarify how you calculated that? I do see some ChatGPT runs around that number, but when I checked FullEnrich on the backend, the numbers don’t match that total. Would be helpful to understand what you’re basing that on so we can look into it further. Also adding a CSV with all the credits costs
Can you please look into the 75k Full Enrich credits that have been used
I can share the spreadsheet, do you have an email? It has sensitive data so wouldn't like to share public
Here's an example We enriched 76 prospects @ 2 credits each. Yet it cost 2032 as per image 1 https://app.clay.com/workspaces/12893/workbooks/wb_hmEGYzrrHnDH
Let me check all of this and get back to you!
https://app.clay.com/workspaces/12893/workbooks/wb_eCrHMvhjFVPM https://app.clay.com/workspaces/12893/workbooks/wb_q7SPmq65S3U2 https://app.clay.com/workspaces/12893/workbooks/wb_U46ghKH2RssA https://app.clay.com/workspaces/12893/workbooks/wb_mBddEnYTFzPt https://app.clay.com/workspaces/12893/workbooks/wb_GxSHUY3ASENS https://app.clay.com/workspaces/12893/workbooks/wb_sMbhh49Myo4q https://app.clay.com/workspaces/12893/workbooks/wb_nBRwoBZ3fzaD https://app.clay.com/workspaces/12893/workbooks/wb_hmEGYzrrHnDH https://app.clay.com/workspaces/12893/workbooks/wb_fDmSGhsM67QV https://app.clay.com/workspaces/12893/workbooks/wb_gPuKXBm9MpD3
We have used 191,633 Clay credits on FullEnrich in the last 11 working days. This is completely incorrect. If we re-run the cells we are charged twice for them (which has happened). Today we have lost 9,774 Clay credits for a total of 560 enriched contacts which should cost 1,120 credits.
% number updated here. Sorry for the spam messages. I'm half asleep and need to get this fixed by the morning
Hey Jonathon, I’ve added the credits back to your account and will follow up once we’ve confirmed what caused the issue. Rest easy—we’ve got it covered.
Thanks for returning todays loss. But we're still missing 163k from the previous two weeks.
Hey Jonathan, Thanks for flagging this - I've passed it along to our engineers and flagged this as a bug. You're also right, it seems like there's more Fullenrich than the previous statement I sent and I've started compiling the affected tables with the "Awaiting Callback" issue here. I opened all the tables, duplicated the view, sorted for "Awaiting Callback," and left the saved view with the table url in there to help track the issue: https://docs.google.com/spreadsheets/d/1GHiS1F-fQlJNTs2ZBM6obgBrZyRxNgtDCVq1RVRJlUY/edit?gid=0#gid=0 Just so we're aligned, for the tables listed under "Tested," in this CSV, do you recall anything specific that might've caused the runs to stall? In the meantime, I've added back the 3,329 credits from the CSV that were still awaiting callback.
Will follow up once I hear more from the team.
Thanks again for looking into this. There's is nothing that we know of that might be causing this issue. The tables just seems to not run correctly. Thanks for attaching the document above. I counted there's 62k credits to be checked in that document. I believe there are far more tables that will need checking for credits to be returned
Another example from a table 594 rows enriched (1,188 credits) Total charged 6,504 credits https://app.clay.com/workspaces/12893/workbooks/wb_onWcgqba9VAu/tables/t_5bi5GFhqMU6d/views/gv_bku7Tywi7myb
Thanks for flagging this— we’re still reviewing everything. In this case, I don’t see any callbacks pending, and deleted rows won’t reflect their actual credit usage in the table. I also noticed a large run on 03/28, which could be part of the discrepancy. If rows are deleted, we’re unable to calculate the credits they consumed directly from the table. Let us know if you have more infos—we’re happy to dig in further.
Bo (. thanks for looking into this. I understand that there aren't any rows awaiting call back, this is the problem here. Only 1,188 credits we're actually spent but due to errors, it is showing a loss of 6,504 credits. This is happening over multiple tables. Can you please provide information on how these credits we're used?
Here is the data list that was uploaded. Comparing the data number in the table to the uploaded amount - nothing was deleted. I don't think this is the correct path of investigation. If data was deleted, it would still need to be a further 2500 enriched cells to make up the additional -5k credit loss Only 594 cells/rows had results from FullEnrich
I also looked back at the sheet provided above and the credit refund only covers cells that are "awaiting callback" This does not address the issue - there is a deeper issue draining credits. Can you please look into how many cells provided a result and base the refund from our output https://app.clay.com/workspaces/12893/workbooks/wb_e2ie2ciBuJn8/tables/t_C8vrn5WgJnEe/views/gv_76tXnNnWhEH2 The above table for example - only 101 cells/rows are "has results" Credits Spent 3,192 Awaiting Callback - 2,350 (1,175 x 2) Cells/Rows with results - 202 (101 x 2) 3,192-202 = 2,990 credits awaiting refund From the current refund process we will only be receiving 2,350 (1,175 x2) Missing credits 2350 -2,992 = -642 This process needs to be replicated for each table to process a full refund of all errors
Hey, I’ve just added 70,000 credits back to your account (+the 13k yesterday) Just to clarify — even if a table looks empty or incomplete, it doesn’t mean those cells didn’t run. We’ve seen some cases where tables on a schedule or with auto-update enabled re-trigger actions after bulk changes, which can cause multiple runs and unexpected credit use. There does seem to be an issue with how “awaiting callback” credits are handled, and we’re still actively investigating that. In the meantime, the credits added should help you move forward, and we’ll follow up once we have more clarity.
Thank you Bo (. - appreciate the reimbursement. We understand that the cells may have run multiple times when that's not what the run logic, process or intention was. The awaiting call back likely charging multiple times and not refunding based on no return or errors. The tables don't have scheduled runs / updates. We're going to sign up with FullEnrich to do a small test to see if the same thing happens when not using Clay credits. hopefully this helps isolate things. We appreciate the reimbursement, but are holding off resuming normal usage given this significant overcharge could happen again, are we able to confirm that any subsequent overcharge whilst awaiting a fix will also be reimbursed?
Bo (. I've created a short video here showing where the credits are being spent but showing why they shouldn't have https://www.loom.com/share/0789494636984114ad6e8902318bb242?sid=f791d69f-6550-4f16-98ec-d4b3297b0478
Hey, Thanks for the video and the detailed context—really helpful. We’re actively investigating, so I’ll let the team take a closer look and get back to you with a more concrete update. From what I can see in the table, it looks like the first run went through, then additional data was added, which may have triggered further runs. I totally get your concern about overcharges, and it’s completely fair to hold off until this is resolved. You don’t need to worry about any future overcharges while we work on a fix—those will absolutely be reimbursed if they happen. Appreciate your patience on this. (Also adding a report by time as it might spark some memory)
No, de-dupe shouldn’t cause data to go missing. What’s more likely is that something re-triggered a run — for example, updating a formula or adding data again. Those kinds of changes can unintentionally kick off re-runs. Let us know if you’d like help tracing what may have caused it.
Thanks, im with you now, yes help on that front would be appreciated.
Hey Bo (. Here's an update on credits which are missing from 2 days of usage. Can you please look at this as soon as possible. We won't be able to run tables Thursday onwards as we will run out of credits Here's a link to a replicated sheet. https://docs.google.com/spreadsheets/d/1bHLNN4rY0T8Gs8dKdI49-P8Gc8fkR-IJw4aGXF7ITog/edit?gid=0#gid=0
Hey — Thanks for sharing all the details. I’ve passed this to our engineering team and re-added the missing credits so you don’t run into issues. I’ll follow up as soon as I hear back from them.
Thanks Bo!