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 — Bug Report: signal.signal() fails in Arrow Flight worker thread in Trino offline store · Issue #6424 · feast-dev/feast

Bug Report: signal.signal() fails in Arrow Flight worker thread in Trino offline store #6424

New issue
Copy link
New issue
Copy link
Closed
#6428
Closed
Bug Report: signal.signal() fails in Arrow Flight worker thread in Trino offline store#6424
#6428
Copy link
Labels
kind/bugpriority/p2

Description

@dbbvitor
dbbvitor
opened on May 20, 2026
Issue body actions

Expected Behavior

When the Feast online container sends a materialization request to the remote offline store server (which, in my case, uses the Trino as offline store via Arrow Flight), the offline store should successfully execute the Trino query and return results without raising any threading-related exceptions.

Current Behavior

The remote offline store server raises a ValueError when processing materialization requests:

ValueError: signal only works in main thread of the main interpreter

This occurs because fsdk/python/feast/infra/offline_stores/contrib/trino_offline_store/trino_queries.py line ~95 calls:

signal.signal(signal.SIGINT, self.cancel)

inside Query.init(). When the offline store is served via Arrow Flight (as a remote offline server), this code executes in an Arrow Flight worker thread — not the main thread. Python's signal.signal() is restricted to the main thread of the main interpreter, causing the hard failure.

Steps to reproduce

1 .Deploy a Feast FeatureStore CR with a remote offline store configuration backed by the Trino offline store (contrib).
2. Ensure the offline store server is running and serving via Arrow Flight (gRPC).
3. Trigger a materialization request from the online container (e.g., feast materialize or via the operator's materialization job).
4. Observe the ValueError: signal only works in main thread of the main interpreter traceback in the offline store server logs.

Specifications

Version: Feast 0.63.0
Platform: Kubernetes/Linux

Possible Solution

Wrap the signal.signal calls in a check using threading.main_thread():

import threading  # add to imports at top of file

class Query(object):
    def __init__(self, query_text: str, cursor: Cursor):
        self.query_text = query_text
        self.status = QueryStatus.PENDING
        self._cursor = cursor

        # Guard the signal.signal() call with a main-thread check so it is
        # only registered when running in the main thread (i.e., 
        # interactive/CLI usage) and is safely skipped when running in
        # Arrow Flight worker threads
        if threading.current_thread() is threading.main_thread():
            signal.signal(signal.SIGINT, self.cancel)
            signal.signal(signal.SIGTERM, self.cancel)

Activity

  1. dbbvitor
    added
    kind/bug
    priority/p2
    on May 20, 2026
  2. mbm-codes commented on May 21, 2026

    @mbm-codes
    mbm-codes
    on May 21, 2026
    Contributor
    More actions

    Hi @dbbvitor,
    Thanks for the detailed investigation on this issue — your root-cause analysis and proposed fix made it straightforward to implement. I went ahead and opened PR #6428 with the change. Feel free to use/adapt anything from it, or take the issue in another direction if you already had a different implementation in mind.

    P.S. It wasn’t clear to me from the issue description whether you were planning to work on it yourself, otherwise I would’ve checked first.

  3. dbbvitor commented on May 21, 2026

    @dbbvitor
    dbbvitor
    on May 21, 2026
    ContributorAuthor
    More actions

    Hi @mbm-codes,
    I was open to working on it, but I see no problem with others working on it.

  4. ntkathole
    closed this as completedin #6428on Jul 1, 2026
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

    kind/bugpriority/p2

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402520 — 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.