Skip to content

Conversation

@kooltuoehias
Copy link
Contributor

Fixes #2067

Description

This PR fixes an issue where Go's append returns nil when appending an empty slice to a nil slice.
I added a check in SafeCopy to ensure we always return []byte{} in this case, along with a new unit test.
I also verified it using the test offered in the issue

Checklist

  • Code compiles correctly and linting passes locally
  • For all code changes, an entry added to the CHANGELOG.md file describing and linking to
    this PR
  • Tests added for new functionality, or regression tests for bug fixes added as applicable

Instructions

  • The PR title should follow the Conventional Commits
    syntax, leading with fix:, feat:, chore:, ci:, etc.
  • The description should briefly explain what the PR is about. In the case of a bugfix, describe or
    link to the bug.
  • In the checklist section, check the boxes in that are applicable, using [x] syntax.
    • If not applicable, remove the entire line. Only leave the box unchecked if you intend to come
      back and check the box later.
  • Delete the Instructions line and everything below it, to indicate you have read and are
    following these instructions. 🙂

Thank you for your contribution to Badger!

@kooltuoehias kooltuoehias requested a review from a team as a code owner December 14, 2025 11:41
In practice, keys processed will always have data, but echo `ParseTs`'s logic to prevent panics as SafeCopy does now produce zero length slices and operates on Entry.Key
This was causing an intermittent cgo segmentation problem on OSX
// ParseKey parses the actual key from the key bytes.
func ParseKey(key []byte) []byte {
if key == nil {
if len(key) < 8 {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kooltuoehias I added this sanity check here. In practice, keys processed anywhere in badger will always have byte data, but because SafeCopy does now produce zero length slices and Entry.Key values are sent to that function in publisher.go, better safe than sorry. This check mimics ParseTs's logic to prevent panics by ensuring the slice has the capacity that it's operating on.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kooltuoehias I added this sanity check here. In practice, keys processed anywhere in badger will always have byte data, but because SafeCopy does now produce zero length slices and Entry.Key values are sent to that function in publisher.go, better safe than sorry. This check mimics ParseTs's logic to prevent panics by ensuring the slice has the capacity that it's operating on.

Many thanks ! Things goes really quick here !

# run tests in sequence
#root
#stream
root
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These mistakenly got commented out in a prior merge.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These mistakenly got commented out in a prior merge.

Thanks for catching the edge case with Entry.Key and the quick merge! Happy to contribute.

@matthewmcneely matthewmcneely merged commit 2a8b604 into dgraph-io:main Dec 15, 2025
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

[BUG]: Empty slice is returned as nil

2 participants