hasura / hasura/graphql-engine

Computed Fields in Post Update Check does not reflect updates as part of update.

Open
#10,142 0 comments 0 reactions 0 assignees View on GitHub
k/bug
Dominant language
TypeScript
Stars
32.1k
Forks
3k
PR merge metrics
PR metrics pending

Description

### Version Information

Server Version: 2.36.3
CLI Version (for CLI related issue):

### Environment

Community
### What is the current behaviour?

Computed Fields when used in the Post Update check does not reflect the updated value as per the updated row.
Scenario:
Need to limit the total number of rows in a table where status is active.
Upon updating a row for Inactive to Active, using a post update check where count of Active <= 5, allow the row to be updated even if the existing count of Active is 5.

### What is the expected behaviour?

Upon updating a row for Inactive to Active, using a post update check where count of Active <= 5, should disallow the row to be updated since the existing count of Active is 5.

Need for post update check is the fact that any row with Active status should be allowed for non status field updates but a new row with previous status != Active to status Active need to be blocked.

### How to reproduce the issue?

1.
create a table with two fields, status and comment.
2.
add 2 rows to table with one status = Active, other with status = Inactive
3.
create a computed field in the table to get the count of total active rows in the table
4.
create a post update check with computed field <= 1
5.
update row where status = Inactive to status = Active.
This allows the update to go through successfully

### Screenshots or Screencast

### Please provide any traces or logs that could help here.

### Any possible solutions/workarounds you're aware of?

None

### Keywords

Computed Fields, Post Update Check

Contributor guide

Open the contributing guide

Research direction

No source files or tests are named. Start by reproducing the two-row computed-field and post-update-check scenario in Hasura, then trace the update-check evaluation; done means an Inactive-to-Active update is rejected when the resulting active count exceeds the limit while non-status updates remain allowed.

Written by the indexing model from the issue text.

Assessment

Domain
authorization, backend, database
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.