Repository navigation
Release 0.78.6 - #3903
Merged
Merged
Release 0.78.6#3903
Conversation
…3870) 23 minor releases of drift. Renovate tracks none of the three places the generator version is pinned (the script default and both CI jobs), which is how it got this far behind. The only behavioural change on the wire is `Accept: application/json`, now sent on 120 operations (30 in v0, 90 in v1). That header is CORS-safelisted, so it adds no preflight. The ~16,500 lines of api.ts churn are almost entirely JSDoc removal: upstream dropped @export, @interface, @type and @memberof from every template. Exported-surface changes, all shape-preserving: - Field enums moved from shared enums to per-model copies, e.g. CourseResource.availability now references CourseResourceAvailabilityEnum with the same values. The shared enums are still exported. - `featured_list` went from a synthesised DepartmentChannelFeaturedList to the shared LearningPathPreview -- identical shape, so this is deduplication. - Three v0 types gained an `Enum` suffix (PatchedProfileRequestCertificateDesired -> ...DesiredEnum). Nothing outside generated/ referenced them. Accompanying changes, each forced by the bump: - CI pins in both openapi-generated-client-check jobs. These regenerate the client and diff it against the checked-in copy, so leaving them at v7.2.0 fails with the misleading "OpenAPI spec is out of date." - globalProperties apiDocs/modelDocs = false in both generator configs. v7.25.0 added api_doc/model_doc templates, which emit 345 markdown files. `docs/**` in .openapi-generator-ignore does not suppress them -- that ignore processor is not gitignore. - modelEnum.mustache rebased onto the v7.25.0 upstream template: adopt the {{#description}} guard, drop @export/@enum. The override exists to emit {{classname}}Descriptions as a runtime const, which is how Django choice labels reach the profile and search selects; upstream only puts enumDescription in a JSDoc comment, where it is lost at runtime. The 31 v0 and 29 v1 Descriptions maps are byte-identical to before. - **/src/generated/** added to the eslint ignorePatterns. v7.25.0's configuration.mustache no longer emits /* eslint-disable */, which surfaces 8 no-explicit-any errors in the two generated configuration.ts files. - HubspotForm defaultValues/default_values widened to (string | null)[] | null, with nulls filtered where the value is derived. v7.2.0 silently dropped item-level `nullable` on arrays; v7.25.0 emits it. Our spec says `default_values: {items: {type: string, nullable: true}}` because _scalar_field in ol_hubspot/schema.py applies allow_null=True to every scalar, including ListField children. Whether HubSpot actually returns null items is not determinable from the SDK -- its openapi_types map cannot express nullability -- so the frontend tolerates them rather than asserting they cannot occur. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
…des (#3882) * Don't publish youtube playlists that have no videos A playlist with zero videos passed the 60% content-match threshold vacuously (0 < 0 is false) and was created published with an empty detail page. Treat an empty match list the same as a failed match so the playlist is skipped or unpublished until its videos appear. Fixes mitodl/hq#13134 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Don't publish podcasts whose feed has no episodes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * Simplify empty-podcast loader test Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * Scope empty-playlist lookup by platform; unpublish episodes of emptied podcasts Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * Mirror the empty-playlist approach for podcasts with no episodes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * Unpublish episodes of a podcast whose feed has no episodes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* adding initial change-over * add server side flag for disabling hybrid search
OpenAPI ChangesNo changes detected Unexpected changes? Ensure your branch is up-to-date with |
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
Comment on lines
+99
to
+104
| const defaultValues = (field.defaultValues ?? field.default_values)?.filter( | ||
| (value): value is string => value !== null, | ||
| ) | ||
|
|
||
| const rawDefaultValue = | ||
| field.defaultValues ?? | ||
| field.default_values ?? | ||
| field.defaultValue ?? | ||
| field.default_value | ||
| defaultValues ?? field.defaultValue ?? field.default_value |
There was a problem hiding this comment.
Bug: If field.defaultValues contains only nulls, it becomes [] after filtering. This empty array prevents the nullish coalescing operator from falling back to field.defaultValue.
Severity: LOW
Suggested Fix
After filtering defaultValues, check if the resulting array is empty. If it is, treat it as undefined to allow the nullish coalescing operator to correctly fall back to field.defaultValue or field.default_value. For example: (filteredValues.length > 0 ? filteredValues : undefined) ?? ....
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location: frontends/ol-components/src/components/HubspotForm/HubspotForm.tsx#L99-L104
Potential issue: In `HubspotForm.tsx`, the code filters `null` values from
`field.defaultValues`. If the original array contains only `null` values (e.g.,
`[null]`), the result is an empty array `[]`. Because an empty array is not a nullish
value, the nullish coalescing operator (`??`) in the assignment of `rawDefaultValue`
does not fall back to `field.defaultValue` or `field.default_value`. This causes the
form field to initialize with an empty value instead of the intended fallback, if one is
provided by the Hubspot API under these specific conditions.
Did we get this right? 👍 / 👎 to inform future reviews.
odlbot
added
waiting for checkboxes
all checkboxes checked
and removed
deploying to rc
waiting for checkboxes
labels
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
renovate[bot]
Shankar Ambady
Matt Bertrand
Chris Chudzicki