You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Additional information supplied by user needs basic header info. This does not have basic info
=== Additional information supplied by user ===
FYI—they were okay at the beginning of the semester. This is a new problem as of this week/recently.
===============================================
The issue stemmed from a lack of error handling for empty header information from additional info supplied from user sections. That has now been fixed with #140
Additional info supplied by user structure:
=== Additional information supplied by user ===
Subject: Subject Line Here
From: "From_Name"<email@aol.com>
Cc: "epicsite@ecn.purdue.edu"<epicsite@ecn.purdue.edu>,
"CC Name One"<ccone@purdue.edu>,
"CC Name Two"<cctwo@purdue.edu>,
"CC Name Three"<ccthree@aol.com>
Date: Mon, 19 Jan 2015 11:30:44 -0500
content...
===============================================
The structure consists of a beginning delimiter, a newline indicating header information, header information, a new line indicating the end of the header information and the beginning of the content, two new lines and the ending delimiter. However, the below queue resulted in an error during the date sort within the api:
=== Additional information supplied by user ===
content
===============================================
The problem with the section above (taken from webmaster 137 in the live queue) was with the handling of the header information. The api does not expect a fixed number of lines within the header, meaning that 0 lines of header information can be included within the reply-from-user section and still result in a successful parse for the rest of the section. However, a line indicating the date of the section must be provided in the header so that the script can sort the section by date, something that was not checked.
In order to successfully parse correctly, the api now looks for a date in the header info and returns a parse_error if none is found.
What Happened
Webmaster 137 broke in the live queue
Expected Behavior
Webmaster 137 shouldn't break
Steps to Reproduce
Logs
Issue fix: implement an error parse that accounts for missing info in the additional info supplied by user section
The text was updated successfully, but these errors were encountered: