-
Notifications
You must be signed in to change notification settings - Fork 73
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
Improved privacy request error handling #5500
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Skipped Deployment
|
fides Run #11114
Run Properties:
|
Project |
fides
|
Branch Review |
refs/pull/5500/merge
|
Run status |
Passed #11114
|
Run duration | 00m 39s |
Commit |
514567e1b2 ℹ️: Merge 9baf5e4931813ad690114a9e4fc8501efd380d9e into 0a7a2b2feb03717bbc5297eb0bc9...
|
Committer | Adrian Galvan |
View all properties for this run ↗︎ |
Test results | |
---|---|
Failures |
0
|
Flaky |
0
|
Pending |
0
|
Skipped |
0
|
Passing |
4
|
Upgrade your plan to view test results. | |
View all changes introduced in this branch ↗︎ |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5500 +/- ##
==========================================
+ Coverage 85.18% 85.19% +0.01%
==========================================
Files 387 387
Lines 24265 24285 +20
Branches 2646 2649 +3
==========================================
+ Hits 20669 20689 +20
Misses 3042 3042
Partials 554 554 ☔ View full report in Codecov by Sentry. |
Consistent privacy request logging New traversal entry in activity timeline
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.
Nice work so far @galvana ! I like how you've fortified our logging by adding additional args into @log_context
decorator.
Can you explain more about how you envision future devs should use this decorator in combination with manual log statements?
clients/admin-ui/src/features/privacy-requests/events-and-logs/ActivityTimeline.tsx
Outdated
Show resolved
Hide resolved
clients/admin-ui/src/features/privacy-requests/events-and-logs/ActivityTimeline.tsx
Outdated
Show resolved
Hide resolved
|
||
type ActivityTimelineProps = { | ||
subjectRequest: PrivacyRequestEntity; | ||
setEventDetails: (d: EventData) => void; | ||
}; | ||
|
||
const hasUnresolvedError = (entries: ExecutionLog[]) => { |
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.
I know this method existed before- but mind adding a short docstring explaining what this does? Specifically- what an "unresolved" error means vs just an error?
clients/admin-ui/src/features/privacy-requests/events-and-logs/EventLog.tsx
Show resolved
Hide resolved
...api/alembic/migrations/versions/c90d46f6d3f2_update_default_timestamps_for_execution_logs.py
Show resolved
Hide resolved
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.
I broke out the TimelineEntry
and LogDrawer
into separate components. I also removed the EventDetails
component since it added unnecessary click before opening the LogDrawer
|
||
def upgrade(): | ||
op.alter_column( | ||
"executionlog", "created_at", server_default=text("clock_timestamp()") |
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.
The previous server_default
for the created_at
and updated_at
columns of ExecutionLog
were set to now()
. This meant that when the execution log entry was written to the database it would use the timestamp from when the database session was opened instead of when the ExecutionLog
entry was created. Changing this to clock_timestamp()
makes it so we don't used the cached timestamp and use the actual event creation time. This value is still calculated on the database so there's no issues with application time inconsistencies in the case of multiple webservers or workers.
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.
This makes sense!
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.
I simplified this so it's easier to understand
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.
Nice work @galvana !
fides Run #11115
Run Properties:
|
Project |
fides
|
Branch Review |
main
|
Run status |
Passed #11115
|
Run duration | 00m 39s |
Commit |
97edac0ea8: Improved privacy request error handling (#5500)
|
Committer | Adrian Galvan |
View all properties for this run ↗︎ |
Test results | |
---|---|
Failures |
0
|
Flaky |
0
|
Pending |
0
|
Skipped |
0
|
Passing |
4
|
Upgrade your plan to view test results. | |
View all changes introduced in this branch ↗︎ |
Closes LA-102 and LA-68
Description Of Changes
This PR contains miscellaneous improvements to the privacy request flow.
Code Changes
Main change
Bug fixes
approved
toin progress
Misc improvements
Dataset traversal
timeline event before the actual request startsSteps to Confirm
fides.toml
nox -s dev -- postgres
, if this fails you might need to runnox -s build
postgres_example
database and run this SQL script postgres_sample.txtpostgres_dataset.txt
postgres_example
database. After saving attach the dataset from the previous stepjane@example.com
Pre-Merge Checklist
CHANGELOG.md
updatedmain
downgrade()
migration is correct and works