breken-ai opened a new pull request, #9186: URL: https://github.com/apache/devlake/pull/9186
### Pre Checklist - [x] I have read through the [Contributing Documentation](https://devlake.apache.org/community/). - [x] I have added relevant tests. - [x] I have added relevant documentation. (No user-facing docs change; the new format entry has a comment.) - [ ] I will add labels to the PR, such as `pr-type/bug-fix`, `pr-type/feature-development`, etc. (I can't set labels from a fork. `pr-type/bug-fix` fits.) ### Summary `ConvertStringToTime` and `ConvertStringToTimeInLoc` (`backend/core/models/common/iso8601time.go`) match timestamps that end in a `+hh:mm` offset against fixed-width layouts: `.000` (3 digits) and `.000000` (6 digits, added in #8828). Any other number of fractional digits fails to parse: | input | source | before | after | |---|---|---|---| | `2026-09-29T10:00:00.1234567+08:00` | .NET round-trip format, e.g. PowerShell `Get-Date -Format o` | `cannot parse "7+08:00" as "-07:00"` | parsed | | `2025-09-15T17:53:36.337932123+09:00` | Go `time.RFC3339Nano`, Java `OffsetDateTime` with nanos | parse error | parsed | | `2025-09-15T10:53:36.3379+02:00` | RFC3339Nano with trailing zeros trimmed | parse error | parsed | This matters because the same function backs the mapstructure decode hook (`helpers/pluginhelper/api/mapstructure.go`). So when a CI script posts a deployment to the webhook plugin with `startedDate`/`finishedDate` in one of these formats, `DecodeMapStruct` fails and `postDeployments` returns 400. That deployment is never stored, so deployment frequency, change lead time and failed deployment recovery time are all computed without it. The same thing happens to webhook incidents and issues. An `Iso8601Time` field in a plugin extractor fails its subtask the same way, which is what #8708 hit with 6 digits. The fix replaces the two fixed-width entries with one entry, `\.[\d]+[+-][\d]{2}:[\d]{2}$`, using the layout `2006-01-02T15:04:05.999999999-07:00`. That layout accepts a fraction of any length. The 3- and 6-digit cases parse exactly as before. ### Does this close any open issues? No open issue. This is a follow-up to #8708 / #8828, which fixed only the 6-digit case. ### Screenshots N/A. Test evidence: - New cases in `TestConvertStringToTime` (7, 9, 4 and 1 fractional digits) and `TestConvertStringToTimeInLoc` (7 digits). - On `main` (`b0a75899`): `go test ./core/models/common/ -run TestConvertStringToTime -v` fails the 7-, 9- and 4-digit cases and the 7-digit `InLoc` case (4 failures). The existing 3/6-digit cases and the 1-digit case pass. - With the fix, all 13 subtests pass and `go test ./core/models/common/` is green. `gofmt -l` and `go vet` are clean. - I also checked the webhook path by calling `api.DecodeMapStruct` on a `{startedDate, finishedDate}` payload with 7- and 9-digit timestamps. It returns an error on `main` and decodes both values with the fix. ### Other Information I used an AI coding assistant (Claude Code) to write this change, following the [ASF generative tooling guidance](https://www.apache.org/legal/generative-tooling.html); the commit carries a `Generated-by:` trailer. -- 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]
