[Dev Log] 2026-07-10

The Beginning of the SK Hynix Report Publishing Troubleshooting

After publishing the SK Hynix ADR listing report, I encountered an unexpected bug. A script error occurred during the conversion process by marked, the markdown parser in the Astro framework, after uploading the HTML body to Strapi CMS. Initially, I prematurely concluded that the marked parser was breaking the JavaScript by forcefully escaping comparison operators (v >= 0) inside script tags into >= format. This resulted in the failure of key JavaScript functionalities such as chart rendering and tab activation.

Furthermore, I discovered a bug where the regular expression applied in the automated upload script upload_skhynix_analysis.py malfunctioned, wiping out entire script blocks. Additionally, during the process of removing the report header and the global body margin (page-wrap), the layout padding was inadvertently removed as well, causing the content to stick to the left edge of the browser, which completely ruined readability.

Hasty Self-Diagnosis and Misguided Workarounds

I took several measures to resolve the issues. I tried to bypass the marked escape issue by rewriting the code to Math.max(0, v) === v, avoiding special characters instead of using comparison operators (v >= 0) in the script. I also modified the regex to match only specific tag units accurately to preserve the bottom script area. To prevent the global layout from being contaminated, I stripped out the top-level body and html selectors and redefined the .page-wrap scope and padding styles, wrapping the content in a new outermost div. I also solved the issue of charts distorting when in a display: none state during tab switching by adding a 50ms delay to force a window resize event.

However, it was later revealed that my hasty self-diagnosis was completely off the mark. The hypothesis that marked escapes comparison operators inside scripts could not even be reproduced. Testing in the actual project version showed that the script blocks were perfectly preserved, and the left margin issue was not the original problem either.

Finding the Real Cause of the Live Site Failure

The real causes were elsewhere. First, the upload script was cutting out the entire HTML header, which inadvertently removed the Chart.js CDN loader. The browser console showed ReferenceError: Chart is not defined, but I had mistakenly identified it as a SyntaxError. This caused all six charts to fail.

Second, in the process of manually picking and moving only the necessary CSS classes, a large number of styles, including alignment, margins, and increment/decrement colors, were omitted. Third, there was a hidden bug where the report's unique --color-* CSS variables conflicted with global site variables, breaking the theme in light mode. Finally, I had forced the original report layout, designed for a 1100px width, into a blog post body with a 720px width limit, causing the table layout to collapse.

Structural Solutions and Deep Lessons

I needed a structural solution rather than a simple patch. First, to prevent manual omissions, I developed a new report_uploader.py module that parses the entire style and automatically converts it to the .page-wrap scope. I also built a build pipeline that preserves CDN scripts and runs automated validation before publishing; if any test fails, the publishing process stops. Now, I use a general-purpose uploader based on a manifest configuration file instead of one-off scripts. I also improved the Astro code on the front-end to increase the column width limit to 1100px for report-style posts and blocked unnecessary prose style interference.

Through this troubleshooting, I learned a bitter lesson: do not rush to guess the cause based on symptoms alone; always thoroughly check the actual error messages in the browser console. Moreover, I realized that manual work, such as picking out CSS one by one, will inevitably lead to mistakes. After making changes, one should not just be satisfied mentally but must verify by directly interacting with the live environment, checking real-time rendering and console logs to ensure there are no lingering issues.

Thoughts for the Day

Since web development is not my specialty, I deeply feel that it is not as easy as I thought. I created the internal data and checked it multiple times, yet the situation keeps going wrong only when I upload it... I've been pulling all-nighters recently that I never expected to spend on blogging...