-
Notifications
You must be signed in to change notification settings - Fork 49
Remove/address depth limitation of parseDateFields #522
Copy link
Copy link
Open
Labels
backendIssues related to the platform backend.Issues related to the platform backend.low priorityLow priority issues to be done eventually.Low priority issues to be done eventually.t-core-servicesIssues with this label are in the ownership of the core services team.Issues with this label are in the ownership of the core services team.t-toolingIssues with this label are in the ownership of the tooling team.Issues with this label are in the ownership of the tooling team.
Description
Metadata
Metadata
Assignees
Labels
backendIssues related to the platform backend.Issues related to the platform backend.low priorityLow priority issues to be done eventually.Low priority issues to be done eventually.t-core-servicesIssues with this label are in the ownership of the core services team.Issues with this label are in the ownership of the core services team.t-toolingIssues with this label are in the ownership of the tooling team.Issues with this label are in the ownership of the tooling team.
Type
Fields
Give feedbackNo fields configured for issues without a type.
parseDateFieldstraverses the provided JSON (used for Apify API responses) and converts certain fields to aDateobject. The traversion depth has been historically limited to 3, possibly to avoid cyclic dependencies and improve performance on large responses.This limitation is not communicated in any way, which might lead to weird surprises. We tried adding a
log.warningbut that led to log pollution as there are objects with arbitrary structure that went over the depth limit (most likely user data, data sets). Context here.Possible solutions:
Both are potential breaking changes.
This is currently not causing any issues and can be treated with low priority.