Writing in the front

This was an online debugging process about 3 months ago. The reason for the final check was very simple, but the debugging process made me understand what the so-called “complicated online environment” means.

Background information

This was the first H5 page requirement I took over after I joined the company. It was also an important internal project, and almost all departments of the company participated in this project. After the project was completed, I got an internal award from the company, which is a story later.

The part I was in charge of was a relatively simple one in the project, including 2 Web management background pages and 5 H5 front-end pages. The management background input data, and then the H5 page pull interface display, while the background data can be directly used by the client. The main work is in my background partner, the front end of the page according to design.

Life is very simple, leisurely one week to finish, and then self test, raise test. PM said they needed to release it together after the downstream client was developed, so they waited for almost 3 weeks.

On release day, there was a bizarre style bug.

BUG Troubleshooting Process

After Posting, my partner’s phone found an H5 page with broken styles. On my phone, it’s perfectly normal

  1. Check the release process

    Gitlab CI packaging normal -> re-release -> found the problem is still

    Conclusion 1: Not yet

  2. Clear the App cache and refresh the page

    Because there is a page cache in the App and it has been pre-released before, I show that it might be the previous cache. First, clear the cache and make sure the page files are newly published.

    After cleaning up, my partner’s phone was still wrong, and so was my phone.

    Conclusion 2: There should be a problem with the CSS file

  3. PC to view

    This page is shared between H5 and PC, so PC can also view it, which is slightly cheaper to debug.

    First of all, the PC also displays abnormal -> Use Chrome DevTool to check whether the CSS file is correctly downloaded -> No CSS file is downloaded

    Conclusion 3: THE CSS file was not downloaded

  4. Check CI release package files

    Found that CSS files are not included in the HTML file of the distribution package –> Found that THE HTML file is not packaged properly because the code formatting causes a packaging bug

    Conclusion 4: CSS files are not packaged properly

  5. On the PC, the CSS file has errors

    After repair and re-release, the bug still exists –> browser devtool can see the corresponding CSS file in network –> Open the CSS file path to check whether the CSS file content is correct –> After keyword search, found that several styles are missing

    Conclusion 5: The CSS file has an error

  6. Download the GitLab package and compare CSS files online and in the distribution package

    Found that the packaged CSS file is different from the online CSS file hash.

    Conclusion 6: The published CSS file is not synchronized with the online CSS file

  7. Accidental: Another colleague noticed that the phone was showing fine

    Another colleague cleared the App cache and the display was normal –> The display of my partner and I’s mobile phones was still wrong, and the PC side was also wrong

    Conclusion 7: CSS files download normally on some phones?? !!!!!!!!!

  8. Switch to the same network condition

    Notice that both my partner and I are connected to the company wifi, while another colleague is using mobile 4G. Is it because the CDN cache is not synchronized?

    Let another colleague connect to the company wifi, clear the cache –> refresh the page, style bug reappear

    Conclusion 8: CDN cache is out of sync?

  9. Add vConsole to compare CSS files that are displayed as normal with those that are not

    Added the version of vConsole temporarily, check the CSS file version on another colleague’s mobile phone -> The CSS file hash displayed normally is different from the abnormal CSS file hash -> the former is the same as the CSS file hash in the GitLab release package, and the latter is the same as the CSS file hash of the last release version

    Conclusion 9: Confirm that CDN cache is out of sync

  10. Repair online

    Minor changes were made to the CSS file in question, the hash file was refreshed, and the bug was immediately fixed

The whole debugging and troubleshooting takes about 3 hours

Cause analysis,

The first bug was a packaging error, and the second bug recurrence should be a typical CDN cache problem.

Because HTML files use the same name and are overwritten, there may be cache synchronization delay. CSS file names are based on hash, so there is no overwrite problem.

So the real bug source is the HTML page file is not synchronized, resulting in access to the new version of the CSS file is not requested. It is understandable that the CSS file was not downloaded the first time the bug appeared, because the packaging was missing and it would not be downloaded. But the second time a bug occurs, the logical combination should be new HTML + no CSS or new HTML + new CSS.

There is no reasonable answer as to why the combination of new HTML and old CSS appears. Because it was in a hurry to release, I did not immediately check the situation after the repair, and now IT is impossible to restore the scene. Ah.

conclusion

In a word, there are a lot of mistakes, lack of experience also leads to a lack of rapid response, disposal methods are also relatively invasive. For example, the old driver probably figured out the cause in the fourth step at most, while my vegetable chicken didn’t realize it until the sixth step. Step 9 can also completely omit a release, use 4G network to open a hotspot through PC debugging.

There’s a long way to go, and I’m going to keep working on it.