Skip to content

[BUG] Unset Outputs in Unit Tests Can Lead to Null Dereferences#7

Merged
matthewphsmith merged 1 commit into
masterfrom
repair-null-output-unit-test
Aug 26, 2019
Merged

[BUG] Unset Outputs in Unit Tests Can Lead to Null Dereferences#7
matthewphsmith merged 1 commit into
masterfrom
repair-null-output-unit-test

Conversation

@matthewphsmith

Copy link
Copy Markdown
Collaborator

In the case an output is unset, the expected behavior is that the output is None for all types. This behavior is embedded in the type engine layer which is accessed via a helper interface. The engine incorrectly bypassed this interface thus breaking that specification. This change uses appropriate helper methods to ensure unpacking of null outputs doesn't result in a null dereference.

@matthewphsmith matthewphsmith merged commit 0c8f72a into master Aug 26, 2019
max-hoffman pushed a commit to dolthub/flytekit that referenced this pull request May 11, 2021
[BUG] Unset Outputs in Unit Tests Can Lead to Null Dereferences
ByronHsu pushed a commit to ByronHsu/flytekit that referenced this pull request May 29, 2023
Signed-off-by: byhsu <byhsu@linkedin.com>
noahjax referenced this pull request in dominodatalab/flytekit Mar 18, 2024
- A service project includes code + docker + helm, but we don't need
   the helm part here since the chart is a shared chart at
   https://github.com/cerebrotech/train-flyteagent-helm

   The docker project type is code + docker
ddl-rliu added a commit to ddl-rliu/flytekit that referenced this pull request Mar 23, 2026
- NOTE: the flytekit 1.16 release changed hash calculation a bit with
  flyteorg#3247, so this commit is a
  little different from what was done on the 1.15.4 version of the
  Domino branch (and the 2 commits for this were squashed into one)

- This is necessary due to another pending PR to upstream flytekit:
  flyteorg#2428

  In case this PR is not likely to be merged, we have a plan to move away
  from this change, see the linked Doc in DOM-57472

  [DOM-68737] Refactor version_hash_additional_context to use bytes (flyteorg#7)

  `bytes` is more flexible. This flexibility is relevant when including the
  serialized input bindings (bytes) in the version hash calculations. This
  is necessary to fix a bug that can occur:

  There is a bug where Flyte rejects a valid workflow. This can happen when
  workflow inputs are read from a file, causing the workflow input bindings
  to be updated, without an update to the version.

  Refactor version_hash_additional_context, which currently uses `str`,
  to use `bytes`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants