Skip to content

Additional info supplied by user Missing Info Parsing #137

Closed
benne238 opened this issue Dec 3, 2020 · 3 comments · Fixed by #140
Closed

Additional info supplied by user Missing Info Parsing #137

benne238 opened this issue Dec 3, 2020 · 3 comments · Fixed by #140
Assignees
Labels
bug An issue that results in webqueue2 breaking

Comments

@benne238
Copy link
Collaborator

benne238 commented Dec 3, 2020

What Happened

Webmaster 137 broke in the live queue

Expected Behavior

Webmaster 137 shouldn't break

Steps to Reproduce

  1. Open webmaster queue in the live wq2

Logs

Issue fix: implement an error parse that accounts for missing info in the additional info supplied by user section

@benne238 benne238 added the bug An issue that results in webqueue2 breaking label Dec 3, 2020
@benne238 benne238 self-assigned this Dec 3, 2020
@benne238
Copy link
Collaborator Author

benne238 commented Dec 3, 2020

The Culprit

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.


===============================================

@benne238
Copy link
Collaborator Author

benne238 commented Dec 3, 2020

webmaster Queue Fix

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.

@campb303
Copy link
Collaborator

campb303 commented Jan 5, 2021

Waiting for #140 to be merged.

@campb303 campb303 added the api label Jan 5, 2021
@campb303 campb303 linked a pull request Jan 5, 2021 that will close this issue
@campb303 campb303 added this to the v1-readonly milestone Jan 5, 2021
@benne238 benne238 closed this as completed Feb 1, 2021
Sign in to join this conversation on GitHub.
Labels
bug An issue that results in webqueue2 breaking
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants