GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — disable_event_timestamp is plumbed into MaterializationTask but no materialization engine reads it · Issue #6936 · feast-dev/feast

disable_event_timestamp is plumbed into MaterializationTask but no materialization engine reads it #6936

New issue
Copy link
New issue
Copy link
Closed
#6956
Closed
disable_event_timestamp is plumbed into MaterializationTask but no materialization engine reads it#6936
#6956
Copy link

Description

@joaquinhuigomez
joaquinhuigomez
opened on Oct 4, 2026
Issue body actions

Expected Behavior

FeatureStore.materialize(..., disable_event_timestamp=True) — and the feast materialize --disable-event-timestamp CLI flag and the feature server's disable_event_timestamp request field that call it — are documented as "materializes all available data using current datetime as event timestamp" (feature_store.py ~L2858, infra/provider.py ~L246). Rows written to the online store under this flag should carry the materialization time as their event timestamp.

Current Behavior

The flag is threaded all the way down (feature_store.py → provider → MaterializationTask.disable_event_timestamp in infra/common/materialization_job.py ~L25) and then nothing reads it: grep -rn disable_event_timestamp sdk/python/feast/infra/materialization sdk/python/feast/infra/compute_engines returns no hits. The source's own event timestamp is written unchanged.

Repro (local provider, sqlite online store, a FileSource whose row is stamped 2020-01-01):

feast apply
feast materialize --disable-event-timestamp
# then get_online_features(...).to_dict(include_event_timestamps=True)

returns event_timestamp = 1577836800 (2020-01-01) for the materialized row — the source value, not the current time.

The flag's other effect — widening the materialization window to "everything" — does happen (and has a separate timezone bug in how it computes the end bound, which I'm sending as a small PR). This issue is only about the documented "use current datetime as event timestamp" behaviour never having been implemented since the flag landed in eb51f00.

Steps to reproduce

  1. feast init a local repo; point a FeatureView at a parquet FileSource with one row whose event_timestamp is 2020-01-01.
  2. feast apply && feast materialize --disable-event-timestamp
  3. Read the row back with get_online_features(...).to_dict(include_event_timestamps=True).
  4. Observe the 2020 timestamp.

Specifications

  • Version: 0.66.1.dev72+g97296c19f (master @ 97296c1)
  • Platform: macOS, Python 3.13
  • Subsystem: materialization (local engine; the flag is unread by every engine under infra/materialization/ and infra/compute_engines/)

Possible Solution

Either implement it — have the materialization engines overwrite the event timestamp column with _utc_now() when task.disable_event_timestamp is set, before the online write — or drop the "current datetime" promise from the three docstrings and let the flag mean only "full window". The first is the documented contract; happy to take it on if a maintainer confirms which engines should honour it (local only, or all).

Activity

  1. patelchaitany commented on Oct 6, 2026

    @patelchaitany
    patelchaitany
    on Oct 6, 2026
    Contributor
    More actions

    Thanks for pointing out this discrepancy! We'll update the docs so disable_event_timestamp only promises full-window materialization, and fix the timezone bug in the end bound. If your PR for that is already open, please link it here.

  2. Toyenzo commented on Oct 6, 2026

    @Toyenzo
    Toyenzo
    on Oct 6, 2026
    More actions

    I'll take this on, implementing the documented contract: when disable_event_timestamp=True, materialized rows written to the online store will carry the current datetime as their event timestamp. I'm scoping the first PR to the local compute engine (the default feast materialize path from the repro), with the other engines as follow-up work.

  3. patelchaitany
    added 2 commits that reference this issue on Oct 7, 2026

    fix: Use UTC end bound and correct docs for disable_event_timestamp

    This issue will close once commit cc13f9d is merged into the 'master' branch.
    cc13f9d

    fix: Use UTC end bound and correct docs for disable_event_timestamp

    This issue will close once commit 4b57b7a is merged into the 'master' branch.
    4b57b7a
  4. ntkathole
    added a commit that references this issue on Oct 7, 2026

    fix: Use UTC end bound and correct docs for disable_event_timestamp

    This issue will close once commit f330e87 is merged into the 'master' branch.
    f330e87
  5. patelchaitany
    added 2 commits that reference this issue on Oct 7, 2026

    fix: Use UTC end bound and correct docs for disable_event_timestamp

    This issue will close once commit 73998ae is merged into the 'master' branch.
    73998ae

    fix: Use UTC end bound and correct docs for disable_event_timestamp

    This issue will close once commit 6251e9f is merged into the 'master' branch.
    6251e9f
  6. ntkathole
    added a commit that references this issue on Oct 9, 2026

    fix: Use UTC end bound and correct docs for disable_event_timestamp

    This issue will close once commit 9617d6e is merged into the 'master' branch.
    9617d6e
  7. ntkathole
    closed this as completedin #6956on Oct 9, 2026
  8. ntkathole
    added 3 commits that reference this issue on Oct 9, 2026

    fix: Use UTC end bound and correct docs for disable_event_timestamp (f…

    This issue will close once commit cc07c82 is merged into the 'master' branch.
    cc07c82

    chore(release): release 0.67.0

    This issue will close once commit 2dfb9e6 is merged into the 'master' branch.
    2dfb9e6

    fix: Merge upstream feast-dev/feast master - resolve CSV conflict (#247)

    This issue will close once commit 2b0b7d7 is merged into the 'master' branch.
    2b0b7d7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.