AP24110011695 opened a new pull request, #3566: URL: https://github.com/apache/tika/pull/3566
### What this fixes A line whose shape matches a cue timing but whose endpoints are both out of range — e.g. `00:61.000 --> 00:62.000` (minutes 61 and 62) — was treated as a cue even though `normalizeTime` returns null for both endpoints. That opened a cue `<div>` **without any timing attributes** and captured the text that followed it. ### Expected behavior Per WebVTT robustness, a `-->` line whose timestamps are invalid should degrade to cue text. Only lines with at least one parseable endpoint should start a cue. ### Changes - `CueWriter.line()` treats a timing-shaped line as a cue only when `normalizeTime` succeeds for at least one endpoint; otherwise the line degrades to cue text like other malformed lines. - Regression test `testInvalidTimingLineIsText`: fails on main (the attribute-less div captures the text), passes with the change; the full 30-test `SubtitleParserTest` suite stays green. ### Notes - Found while probing the newly-added subtitle parser (TIKA-5028) with edge-case inputs. - Tried to file a Jira issue first; the self-serve response pointed us to submit via GitHub, so this PR carries the report and fix together. - AI usage disclosure: investigated, fixed and verified with AI assistance under the contributor's direction; the contributor reviewed the diff line by line and ran the full test suite locally. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
