-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
handle unknown index types gracefully in iUtils #18
Conversation
hey @xvrl, could you please take a look when you get a chance? |
Hi @alperkokmen, I'm not sure I'm the best person to review this. @drcrallen looks like you've made changes to this logic before, mind taking a look? |
just came across a new issue (#19) that these changes would take care of. @drcrallen, could you please take a look? |
bump – @drcrallen, could you please take a look or tag someone who can review/merge this change? thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add a unit test for this behavior?
when 1b74f29 added support to handle archive tasks, it introduced a new matching group for the regular expression in parseTaskId which shifted the indexing for resulting matches (i.e. m). to simplify things, i am making marking the outer group as don't-capture-just-group (?:) to keep the matching result consistent. as a result, type will be populated using m[3], m[2], or m[1]. m[4] will always be the datsource; m[5] will be the timestamp. this change adds unit tests to demonstrate the expected parseTaskId output for various tasks type supported. it also covers the error case when taskId doesn't match the regular expression.
this updates parseTaskId in iUtils.coffee which uses a somwhat strict regular expression to parse a given task id and extract type, datasource, and time. this simply removes throwing the error and falls back to 'other' for type leaving dataSource and dataTime alone. in case of a match failure, they would just default to undefined which isn't a blocker to render /indexing-service view.
77575d7
to
ea4f4db
Compare
@clintropolis i found out |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome thanks! LGTM 👍
👍 |
this updates
parseTaskId
iniUtils.coffee
which uses a somwhat strict regular expression to parse a given task id and extracttype
,datasource
, and time (relates to #3 and #9).this simply removes throwing the error and falls back to
'other'
for type leavingdataSource
anddataTime
alone. in case of a match failure, they would just default to undefined which isn't a blocker to render/indexing-service
view.