This topic was automatically generated from Slack. You can find the original thread here.
I’m struggling with a step in workflow. I’m trying to update a database in Coda.io using row-id as the unique identifier. It logs 404 - Not Found - Could not find a row with the specified ID or name. I’ve already got a step in my workflow that creates the record in the first place and returns the row-id. When I test the individual update step, it works fine - however this error happens when I test the whole workflow. I noticed there was step called Get Row, which I thought might address the issue as a precursor to running the additional update step, but that too fails in workflow. Any ideas or is this a bug?
It sounds like you’re encountering an issue with updating a row in Coda using the row ID as the unique identifier within a Pipedream workflow. Given that the update step works fine when tested individually but fails during the full workflow execution, and considering the error message you’re receiving, there are a few potential issues to consider: 1. Timing Issue: If the record creation and update steps are executed in quick succession, the update step might be running before the new row is fully registered in the Coda database. This could result in a “Not Found” error because the row ID doesn’t exist at the time of the update attempt. 2. Incorrect Row ID: Ensure that the row ID being passed to the update step is correct and matches the format expected by Coda. Since you mentioned that the creation step returns the row ID, double-check that this ID is being correctly passed and used in the update step. 3. Workflow Configuration: Since the Get Row step also fails, it’s possible there might be a misconfiguration in how you’re passing the row ID or other necessary identifiers (like Doc ID or Table ID) between steps in your workflow. To troubleshoot this issue, consider the following steps: - Add a Delay: If the issue is timing-related, try adding a delay between the record creation and update steps. This can give Coda enough time to register the new row before you attempt to update it. You can use the built-in Delay action in Pipedream for this purpose. - Verify Row ID Passing: Make sure that the row ID returned from the creation step is correctly passed to the update step. You can use the steps object to access outputs from previous steps. For example, if your creation step is named create_row, you can access its output using steps.create_row.$return_value. - Check Doc ID and Table ID: Ensure that the Doc ID and Table ID are correctly configured in both the Get Row and Update Row steps. These identifiers must match the actual IDs in your Coda document. - Test with Hardcoded Values: As a diagnostic step, try hardcoding the row ID (and possibly the Doc ID and Table ID) in the Get Row and Update Row steps to confirm that the issue isn’t with the dynamic passing of these identifiers. - Review Pipedream Documentation: For specific instructions on using the
I have tried adding delays and it stills happens. I have verified all the Row, Doc & Table IDs - I’m not quite sure what you mean about ‘hardcoding’ but I altered my workflow to specific a specific option with corresponding associated row ID and that worked fine.
It sounds like you’re experiencing issues with delays in your workflow, and you’ve already verified the IDs for your rows, documents, and tables. You also mentioned that specifying a specific option with its associated row ID worked fine, which suggests that the issue might be related to how you’re handling dynamic data or parameters in your workflow. Since you’ve already tried adding delays and verified the IDs, let’s focus on the concept of ‘hardcoding’ and how it might relate to your issue. Hardcoding means specifying explicit values in your code or workflow instead of using dynamic data that might change. When you mentioned that altering your workflow to specify a specific option with its associated row ID worked fine, it suggests that when you use explicit, known-good values, your workflow behaves as expected. This could indicate that the issue arises when your workflow tries to use dynamic data that isn’t correctly formatted or retrieved. Here are a few steps you can take to troubleshoot and potentially resolve this issue: 1. Review Data Retrieval: Ensure that any dynamic data you’re using in your workflow (like row IDs or document IDs) is being correctly retrieved and formatted. This might involve checking any steps that fetch or generate this data to ensure they’re working as expected. 2. Log and Inspect: Use logging to inspect the dynamic data at various points in your workflow. This can help you verify that the data is what you expect it to be and that it’s correctly formatted for use in later steps. 3. Compare Hardcoded vs. Dynamic: Since you’ve found that hardcoded values work, compare the hardcoded values with the dynamic values you’re trying to use. Look for any discrepancies in formatting or data type that might explain why one works and the other doesn’t. 4. Implement Error Handling: If possible, add error handling to your workflow to catch and log errors when they occur. This can provide more insight into what might be going wrong when your workflow attempts to use dynamic data. 5. Consult Documentation: Review the documentation for any services or APIs you’re integrating with in your workflow. There might be specific requirements or limitations related to the data you’re trying to use. If you’ve tried these steps and are still encountering issues, it might be helpful to reach out for more specific support. You can visit Support - Pipedream for more help. Remember, when working with dynamic data, ensuring that the data is correctly retrieved
this is good, general problem solving advice - but have you forgotten that the update step works fine when tested individually but fails during the full workflow execution? I think it could be a genuine bug.
It sounds like you’re experiencing an issue where an update step works as expected when tested individually, but fails during the full workflow execution. This discrepancy can indeed be frustrating and might suggest a more complex issue at play, potentially even a bug. Given the situation, I recommend the following steps to further diagnose and potentially resolve the issue: 1. Review the Context of the Step: Ensure that the update step is receiving the expected inputs during the full workflow execution. Sometimes, the data passed from previous steps might not be what you expect, leading to failures. 2. Check for Race Conditions: If your workflow involves asynchronous actions or relies on external services’ responses, ensure that the update step isn’t executing before necessary data becomes available. 3. Inspect Logs for Errors: Review the execution logs for the full workflow run to identify any error messages or warnings that could provide clues about the failure. 4. Isolate the Issue: Try to replicate the issue in a simplified version of your workflow. This can help determine if the problem lies within the update step itself or the interaction with other steps. 5. Reach Out for Support: Since you suspect this could be a genuine bug, it would be beneficial to bring this to the attention of the Pipedream support team. You can reach out for more specialized assistance by visiting Support - Pipedream. Sharing detailed information about your workflow, the specific step that’s failing, and any relevant logs or error messages will help the support team diagnose the issue more effectively. Remember, intermittent issues or those that only manifest under specific conditions can be particularly challenging to diagnose. Providing as much context and detail as possible when seeking support will facilitate a quicker resolution.
Okay - so I used another option, upsert row as I had another unique identifier to hand exported as a step - that worked fine - I genuinely think there is bug in the update row module. How do I got about reporting this for the pipedream engineers to look into?
To report a bug in the update row module or any other feature on Pipedream, you can follow these steps: 1. Visit the Pipedream GitHub issues page. 2. Click on “New issue” and select “Bug report” to start documenting the issue you’ve encountered. 3. Fill out the form with as much detail as possible about the bug, including the steps to reproduce it, expected behavior, and actual behavior. The Pipedream engineering team will review your report and follow up on the GitHub issue you’ve created. This is the best way to ensure that the bug is tracked and addressed. For more information on reporting bugs or requesting new features, please see the Pipedream documentation on troubleshooting and reporting a bug or feature request.