Appwrite: Fix Execution Log Cutoff Bug On Small Pages

by SLV Team 54 views
🐛 Bug: Execution Log Sheet Content Cutoff with Small Page Sizes

Hey guys! We've got a pesky bug report here concerning Appwrite's console, specifically how it displays execution logs when you're using smaller page sizes. Let's dive into the details and see what's going on.

Reproduction Steps

So, if you want to see this bug in action, here’s what you gotta do:

  1. Head over to Functions in your Appwrite console. Then, pick any function and click on the Executions tab. It's where all the action happens, right?
  2. Now, change the "Executions per page" setting to 6 rows. This is where the trouble begins.
  3. Click on any of the execution rows to open up the execution details sheet. This sheet should give you all the juicy info about that execution.
  4. Scroll down in the sheet to check out the log response. This is where you'll see if the bug is present.
  5. If you have the bug, you'll notice that long log outputs are cut off, and you can't see everything. Bummer!

Important Note: This issue only pops up when you select 6 rows per page. If you choose 12, 24, 48, or 96 rows, the main page becomes scrollable, and the sheet expands correctly, showing you the full execution logs. It’s weird, I know.

Expected Behavior

Ideally, no matter how many rows per page you select, the execution sheet should behave like a champ. Here's what we expect to see:

  • Display complete execution details. No cutting off important info!
  • Allow vertical scrolling within the sheet so you can view those long log responses without any hassle.
  • Show the full contents of the Request and Response sections. No hiding anything!

Actual Behavior

Unfortunately, when "6 rows per page" is selected, things go south:

  • The sheet content is constrained to the viewport height. It's like it's trapped in a tiny box.
  • Scrolling isn’t available inside the sheet. You're stuck with what you see, even if it's incomplete.
  • Long log responses in the Response accordion are cut off. Super frustrating when you're trying to debug something.
  • Users can't view complete execution logs. This makes troubleshooting a real pain.

Why this happens:

Let's break down why this bug occurs. It's all about how the page and sheet interact with each other:

  • With only 6 table rows, the main page doesn’t scroll. There's just not enough content to make it scrollable.
  • The fixed-height sheet becomes trapped within the viewport. It can't expand beyond the visible area.
  • The sheet lacks internal scroll (overflow-y) for long content. It needs its own scrollbar to handle the overflow.
  • Larger page sizes work because the main page becomes scrollable and the sheet has more vertical room. The sheet can expand as needed.

Appwrite Version

This bug was spotted in Version 1.8.x.

Your Environment

Here’s the setup where this bug was observed:

  • Browser: Chrome 122.0.6261.112 (64-bit)
  • OS: Windows 11 Home (24H2, Build 26100.6584)
  • Console Version: 1.8.0

Have you spent some time to check if this issue has been raised before?

The reporter confirmed that they checked and didn't find a similar issue. Good job on the due diligence!

Have you read the Code of Conduct?

The reporter also confirmed that they have read the Code of Conduct. Awesome!

Diving Deeper into the Technical Details

Okay, let's get a little more technical to understand why this is happening. It all boils down to how CSS handles the height and overflow of elements within the Appwrite console. When the "Executions per page" is set to 6, the main page doesn't have enough content to trigger a scrollbar. This means the viewport's height is essentially the maximum height available for the execution details sheet.

The execution details sheet, likely implemented as a modal or overlay, has a fixed height. This is a common practice to ensure a consistent user interface. However, when the content inside the sheet exceeds this fixed height, and there's no overflow-y: auto; or overflow-y: scroll; applied to the sheet, the content gets cut off. The sheet needs its own internal scrollbar to handle situations where the content is larger than the allocated space.

When you increase the "Executions per page" to 12 or more, the main page becomes scrollable. This indirectly provides more vertical space for the execution details sheet. The sheet can then expand without being constrained by the viewport's initial height, and the content is no longer cut off. However, this isn't a real fix, but rather a workaround that exposes the underlying issue.

The core problem is the lack of a scrollbar within the execution details sheet itself when the content overflows its fixed height.

Potential Solutions and Workarounds

So, what can be done to fix this? Here are a few potential solutions:

  1. Implement overflow-y: auto; or overflow-y: scroll; on the execution details sheet: This is the most straightforward solution. By adding this CSS property, the sheet will automatically display a scrollbar when the content exceeds its height. This ensures that all content is accessible, regardless of the main page's scroll state.
  2. Dynamically adjust the height of the execution details sheet: Instead of using a fixed height, the sheet's height could be dynamically adjusted based on the content within it. This would require some JavaScript to calculate the content's height and set the sheet's height accordingly. However, this approach can be more complex and might lead to performance issues if not implemented carefully.
  3. Use a virtualized scrolling component: For very long execution logs, a virtualized scrolling component could be used. This component only renders the visible portion of the content, which can significantly improve performance. However, this is a more advanced solution that requires more effort to implement.

Workarounds:

In the meantime, here are a couple of workarounds that users can use:

  • Increase the "Executions per page" setting: As mentioned earlier, increasing the number of rows per page will make the main page scrollable, which indirectly fixes the issue.
  • Use the browser's zoom feature: Zooming out in the browser can reduce the content's size, potentially making it fit within the sheet's fixed height.

Impact and Severity

While this bug might seem minor, it can have a significant impact on the user experience. Developers rely on execution logs to debug their functions and identify issues. When these logs are cut off, it becomes much more difficult to troubleshoot problems. This can lead to wasted time and frustration.

Severity: Medium. While there are workarounds, the bug directly impacts a core debugging workflow.

Conclusion

This execution log cutoff bug is a prime example of how seemingly small UI issues can have a significant impact on usability. By implementing a proper scrolling mechanism within the execution details sheet, Appwrite can ensure that developers have access to the complete information they need to debug their functions effectively. Let's hope the Appwrite team jumps on this one soon! Keep coding, folks!