Skip to content

fix: Use batch source timestamp column names in remote online writes - #6752

Open
arose26 wants to merge 1 commit into
feast-dev:masterfrom
arose26:fix/remote-write-timestamp-column-names
Open

fix: Use batch source timestamp column names in remote online writes#6752
arose26 wants to merge 1 commit into
feast-dev:masterfrom
arose26:fix/remote-write-timestamp-column-names

Conversation

@arose26

@arose26 arose26 commented Aug 18, 2026

Copy link
Copy Markdown

What this fixes

Closes #6595.

RemoteOnlineStore.online_write_batch labelled the timestamps in its request body
with the literals "event_timestamp" and "created":

columnar_data["event_timestamp"].append(_to_naive_utc(event_ts).isoformat())
columnar_data["created"].append(...)

The feature server rebuilds that frame verbatim (pd.DataFrame(request.df) in
feature_server.py) and hands it to the standard conversion, which resolves the
timestamp columns by the names the feature view's batch source configures
(sdk/python/feast/utils.py, _convert_arrow_fv_to_proto):

table.column(feature_view.batch_source.timestamp_field)
table.column(feature_view.batch_source.created_timestamp_column)

So for any feature view whose source sets timestamp_field or
created_timestamp_column to something other than those two literals, the client
emits the column under one name and the server looks it up under another:

KeyError: 'Field "created_at" does not exist in schema'

The timestamp value is never lost — it is on the wire, just labelled with a name the
server does not look up. Client and server simply disagree on the column names.

The change

Resolve both column names from the feature view's batch source, falling back to the
previous literals when a name is not configured. That keeps the payload byte-identical
for the default-named case (which is why the existing
test_unix_timestamp_value_serialized_as_int still passes unchanged) and makes the
custom-named case round-trip.

This is the only site with the hardcoding — _convert_arrow_odfv_to_proto synthesizes
its own timestamps and is unaffected, and no other caller builds this payload.

Tests

Two tests in TestRemoteOnlineStoreWriteBatch, both failing before the change:

  • test_timestamp_columns_use_batch_source_names — asserts the request body labels the
    timestamps with the configured names.
  • test_write_batch_payload_round_trips_through_server_conversion — the one that
    actually pins the contract: it takes the payload this client produced, rebuilds the
    frame the way the server does, runs _convert_arrow_fv_to_proto on it, and asserts
    both timestamps survive. Without the fix this test reproduces the reported
    KeyError: 'Field "..." does not exist in schema' directly.
sdk/python/tests/unit/infra/online_store/test_remote_online_store.py  30 passed

Wider check: every unit test file touching the remote / write_to_online_store /
_convert_arrow paths (22 files) gives 219 passed, 5 skipped both with and without this
change. The 11 collection errors in that set are pre-existing missing optional
dependencies in my environment (sqlite_vec, boto3, redis, …), identical on both
sides. ruff check, ruff format and mypy feast/infra/online_stores/remote.py are
clean.


🤖 Written with Claude Code (Claude Opus 5), reviewed by @arose26.

@arose26
arose26 requested a review from a team as a code owner August 18, 2026 10:50
RemoteOnlineStore.online_write_batch labelled the timestamps it sent to
the feature server with the literals "event_timestamp" and "created".
The server rebuilds the frame and resolves those columns by the names the
feature view's batch source configures, so any feature view using a
different timestamp_field or created_timestamp_column failed server-side
with KeyError: 'Field "..." does not exist in schema'.

The timestamp values were never lost, only labelled with names the server
does not look up. Resolve both column names from the batch source, and
keep the previous literals as the fallback when a name is not configured.

Closes feast-dev#6595

Signed-off-by: arose26 <145766958+arose26@users.noreply.github.com>
@arose26
arose26 force-pushed the fix/remote-write-timestamp-column-names branch from 66b7790 to 800af7f Compare August 18, 2026 10:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

1 participant