Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Bug]: write normalizes whitespace-bearing segments silently while extraction keeps interior spaces — silent fork

Open Beginner friendly
#6,521 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
82/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
backend

Research direction

Start by reading openviking/utils/path_safety.py, especially _normalize_storage_segments and normalize_storage_target_uri, then compare _portable_uri_segment in openviking/session/memory/utils/uri.py with sanitize_segment in openviking_cli/utils/uri.py. Reproduce the naming asymmetry with the provided Python snippet and trace the write path in openviking/storage/content_write.py; add or update focused tests for normalization and write/edit behavior. Done means whitespace-bearing targets either fail or warn clearly, or write and extraction use the same normalization, with no silent split into two entries.

Written by the indexing model from the issue text.

Description

Issue Origin

Observed or reproduced in a real environment

Bug Description

Write/edit silently maps a requested URI to a different stored URI when a path segment contains whitespace (space → _), returning success with no warning. The extraction-side naming function treats interior spaces as portable and keeps them, so space-bearing files keep being created; read-then-edit on such a file forks into two entries.

Steps to Reproduce

Naming asymmetry (minimal reproduction, no data written):

from openviking.utils.path_safety import normalize_storage_target_uri
from openviking.session.memory.utils.uri import _portable_uri_segment

print(normalize_storage_target_uri("viking://user/test_user/memories/a b.md"))
# viking://user/test_user/memories/a_b.md
print(_portable_uri_segment("a b.md"))
# a b.md

Observed fork case (initial state: the space-bearing file was produced by memory extraction, which permits interior spaces):

  1. A space-bearing file already exists (content X).
  2. Read-then-edit via that same space-bearing URI: edit reads the old file and writes to the same URI; the write is normalized to the underscore-named file (content X plus the edit), returning success with no warning.
  3. Result: the old space-bearing file and the new underscore-named file coexist.
Expected Behavior

Either of the following:

  • Write/edit loudly refuses or warns when the target is normalized to a different name than requested (preferred, given the Windows-portability intent behind #4308/#4517); or
  • Extraction and write normalize symmetrically so the same logical name never forks.
Actual Behavior

Write/edit returns success on a different target than requested, with no error or warning; two entries coexist.

Minimal Reproducible Example

The naming-asymmetry snippet above is the minimal reproduction.

Error Logs

None — the call succeeds; that is the problem.

OpenViking Version

0.5.1.1

Python Version

3.13.13

Operating System

macOS (Build 26A428)

Additional Context

Source references (pinned to commit 172d4d9e2e1f568634601be6a3e763e9fc64a56d):

Background, not disputed: #4308 (Windows trailing-space file I/O failure) is the reason for the portability guard; this report asks for loud-or-symmetric behavior, not for allowing spaces.

— Pi

Dominant language
Python
Stars
40.2k
Forks
3.2k
Avg merge
1d 4h
Merged PRs (30d)
403

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from volcengine/OpenViking

All issues in volcengine/OpenViking

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.