plexora 0.0.2__tar.gz → 0.0.7__tar.gz

{plexora-0.0.2/plexora.egg-info → plexora-0.0.7}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: plexora
-Version: 0.0.2
+Version: 0.0.7
 Summary: OpenSeadragon-based cellular image viewing and analysis tool.
 License-Expression: LicenseRef-Plexora-Academic-1.0
 Requires-Python: <3.14,>=3.12
@@ -14,6 +14,7 @@ Requires-Dist: itsdangerous>=2.2
 Requires-Dist: Jinja2>=3.1
 Requires-Dist: numpy>=2.0
 Requires-Dist: ome-types>=0.6.3
+Requires-Dist: openpyxl>=3.1
 Requires-Dist: orjson>=3.11
 Requires-Dist: pandas>=3.0.5
 Requires-Dist: Pillow>=10.4
@@ -28,6 +29,7 @@ Requires-Dist: shapely>=2.1.2
 Requires-Dist: spatialdata>=0.8.0
 Requires-Dist: threadpoolctl>=3.6.0
 Requires-Dist: tifffile>=2026.7.31
+Requires-Dist: urllib3>=2.0
 Requires-Dist: waitress
 Requires-Dist: Werkzeug>=3.1
 Requires-Dist: zarr>=3
@@ -72,12 +74,19 @@ There are four ways to run Plexora, all of which end in the same viewer:
 | --- | --- |
 | Your own machine, a terminal | `plexora` |
 | Your own machine, a notebook | `plexora.view("my_dataset")` |
-| A remote machine you can ssh into | `plexora connect user@host` — or `plexora --remote` on the host |
-| A hosted notebook (JupyterHub, Open OnDemand, Colab) | `plexora.view("my_dataset")` — the proxy is detected for you |
+| A remote machine you can ssh into | **Settings → Remote servers → Connect** — or `plexora connect user@host` |
+| A hosted notebook or an HPC terminal | `plexora` — it works out where it is running and prints a URL that works |
 
-**[DEPLOYMENT.md](DEPLOYMENT.md) walks through all of them in detail**, from a
-fresh conda environment to HPC job submission, with the real output of each
-command. The rest of this README is the short version.
+Save a remote server once and reconnecting is a button: Plexora handles the SSH
+connection, the ports, the tunnel and the URL, and relays a password or 2FA
+prompt to the page if the server asks for one. It never stores the password.
+
+**[docs/SETUP_GUIDE.md](docs/SETUP_GUIDE.md)** is the step-by-step version for
+people who would rather not learn about tunnels — organised by where your data
+is, with a compatibility matrix and a screenshot for every screen.
+**[DEPLOYMENT.md](DEPLOYMENT.md)** is the same ground for a technical reader,
+from a fresh conda environment to HPC job submission, with the real output of
+each command. The rest of this README is the short version.
 
 ### Where your data lives
 
@@ -147,9 +156,11 @@ If the remote `plexora` is not on a non-interactive `PATH` — which is common
 with conda — name it explicitly:
 
 ```bash
-plexora connect user@server.lab.edu --remote-command "conda run -n imaging plexora"
+plexora connect user@server.lab.edu --remote-command /home/you/miniconda3/envs/imaging
 ```
 
+The environment path is enough — `bin/plexora` is filled in for you.
+
 **Or do it by hand.** On the remote machine:
 
 ```bash
@@ -166,13 +177,13 @@ Plexora belongs in a job. `--srun` submits one and tunnels to whichever node
 the scheduler grants — the target is the *login* node:
 
 ```bash
-plexora connect user@o2.hms.harvard.edu --srun "-p interactive -t 4:00:00 --mem 16G"
+plexora connect user@o2.hms.harvard.edu --srun "-p interactive -t 4:00:00 -c 16 --mem 128G"
 ```
 
 Allocation may queue; it says so while it waits. Ctrl+C ends the job.
 
 By hand, the same thing is two steps: start an interactive job
-(`srun --pty -p interactive -t 4:00:00 --mem 16G bash`), then run
+(`srun --pty -p interactive -t 4:00:00 -c 16 --mem 128G bash`), then run
 `plexora --remote` inside it. It detects the job, works out which compute node
 it is on and which login node you came through, and prints the two-hop
 `ssh -J` command for it.
@@ -210,6 +221,29 @@ The image also sets `PLEXORA_HOST=0.0.0.0` — published ports would never reach
 it otherwise — and `PLEXORA_DOCKER=1`, which switches the import page to
 container-shaped path hints.
 
+## Data on more than one machine
+
+Sometimes the image and the cell table are not on the same computer — the slide
+is on cluster scratch and the `.h5ad` came back to your laptop. Start a **data
+node** where the data is:
+
+```bash
+plexora node serve --serve image:tumor=/scratch/me/tumor.ome.tif
+```
+
+It prints a token. Register the node in the viewer under **Settings → Data
+nodes**, then point a project at it from that project's **Edit** page, under
+*Where the data lives*.
+
+A node is a Plexora with the viewer switched off: it holds files and answers
+questions about them. Your projects, ROIs, gates and figures all stay on the
+machine you are looking at, so a node can restart or disappear without any of
+your work being at risk — the project still opens, and whatever came from that
+node is absent and says so.
+
+See [DEPLOYMENT.md](DEPLOYMENT.md#7-data-on-more-than-one-machine) for the
+tunnel recipes, what actually crosses the network, and the limits.
+
 ## Clone and Run Codebase (for Developers)
 
 ```bash

{plexora-0.0.2 → plexora-0.0.7}/README.md

@@ -31,12 +31,19 @@ There are four ways to run Plexora, all of which end in the same viewer:
 | --- | --- |
 | Your own machine, a terminal | `plexora` |
 | Your own machine, a notebook | `plexora.view("my_dataset")` |
-| A remote machine you can ssh into | `plexora connect user@host` — or `plexora --remote` on the host |
-| A hosted notebook (JupyterHub, Open OnDemand, Colab) | `plexora.view("my_dataset")` — the proxy is detected for you |
+| A remote machine you can ssh into | **Settings → Remote servers → Connect** — or `plexora connect user@host` |
+| A hosted notebook or an HPC terminal | `plexora` — it works out where it is running and prints a URL that works |
 
-**[DEPLOYMENT.md](DEPLOYMENT.md) walks through all of them in detail**, from a
-fresh conda environment to HPC job submission, with the real output of each
-command. The rest of this README is the short version.
+Save a remote server once and reconnecting is a button: Plexora handles the SSH
+connection, the ports, the tunnel and the URL, and relays a password or 2FA
+prompt to the page if the server asks for one. It never stores the password.
+
+**[docs/SETUP_GUIDE.md](docs/SETUP_GUIDE.md)** is the step-by-step version for
+people who would rather not learn about tunnels — organised by where your data
+is, with a compatibility matrix and a screenshot for every screen.
+**[DEPLOYMENT.md](DEPLOYMENT.md)** is the same ground for a technical reader,
+from a fresh conda environment to HPC job submission, with the real output of
+each command. The rest of this README is the short version.
 
 ### Where your data lives
 
@@ -106,9 +113,11 @@ If the remote `plexora` is not on a non-interactive `PATH` — which is common
 with conda — name it explicitly:
 
 ```bash
-plexora connect user@server.lab.edu --remote-command "conda run -n imaging plexora"
+plexora connect user@server.lab.edu --remote-command /home/you/miniconda3/envs/imaging
 ```
 
+The environment path is enough — `bin/plexora` is filled in for you.
+
 **Or do it by hand.** On the remote machine:
 
 ```bash
@@ -125,13 +134,13 @@ Plexora belongs in a job. `--srun` submits one and tunnels to whichever node
 the scheduler grants — the target is the *login* node:
 
 ```bash
-plexora connect user@o2.hms.harvard.edu --srun "-p interactive -t 4:00:00 --mem 16G"
+plexora connect user@o2.hms.harvard.edu --srun "-p interactive -t 4:00:00 -c 16 --mem 128G"
 ```
 
 Allocation may queue; it says so while it waits. Ctrl+C ends the job.
 
 By hand, the same thing is two steps: start an interactive job
-(`srun --pty -p interactive -t 4:00:00 --mem 16G bash`), then run
+(`srun --pty -p interactive -t 4:00:00 -c 16 --mem 128G bash`), then run
 `plexora --remote` inside it. It detects the job, works out which compute node
 it is on and which login node you came through, and prints the two-hop
 `ssh -J` command for it.
@@ -169,6 +178,29 @@ The image also sets `PLEXORA_HOST=0.0.0.0` — published ports would never reach
 it otherwise — and `PLEXORA_DOCKER=1`, which switches the import page to
 container-shaped path hints.
 
+## Data on more than one machine
+
+Sometimes the image and the cell table are not on the same computer — the slide
+is on cluster scratch and the `.h5ad` came back to your laptop. Start a **data
+node** where the data is:
+
+```bash
+plexora node serve --serve image:tumor=/scratch/me/tumor.ome.tif
+```
+
+It prints a token. Register the node in the viewer under **Settings → Data
+nodes**, then point a project at it from that project's **Edit** page, under
+*Where the data lives*.
+
+A node is a Plexora with the viewer switched off: it holds files and answers
+questions about them. Your projects, ROIs, gates and figures all stay on the
+machine you are looking at, so a node can restart or disappear without any of
+your work being at risk — the project still opens, and whatever came from that
+node is absent and says so.
+
+See [DEPLOYMENT.md](DEPLOYMENT.md#7-data-on-more-than-one-machine) for the
+tunnel recipes, what actually crosses the network, and the limits.
+
 ## Clone and Run Codebase (for Developers)
 
 ```bash

{plexora-0.0.2 → plexora-0.0.7}/plexora/__init__.py

@@ -2,17 +2,30 @@ import multiprocessing
 
 multiprocessing.freeze_support()
 
-from flask import Flask, request
+from flask import Flask, jsonify, request
 from pathlib import Path
 
 import hmac
 import os
-
-# Initialize sklearn global threadpool controller to avoid deadlock in threaded
-# contexts.
-from threadpoolctl import threadpool_limits
-
-threadpool_limits()
+import threading
+
+# Cap every numeric thread pool at this process's REAL CPU allocation, and do
+# it here -- before anything numeric is imported -- so the environment
+# variables OpenBLAS/MKL/OpenMP read at load time are already in place.
+#
+# This replaces a bare `threadpool_limits()`, which capped nothing: threadpoolctl
+# only applies a limit when one is passed, so that call's only effect was to
+# force the BLAS libraries to load. That effect mattered (it is what stops two
+# request threads racing to load them and deadlocking) and is preserved --
+# configure_thread_pools() calls threadpool_limits with a real limit, which
+# loads them just the same.
+#
+# See plexora._resources for why os.cpu_count() is the wrong question here: on
+# a 2-core SLURM allocation carved out of a 64-core node it reports 64, and the
+# resulting oversubscription is what buried the server on HMS O2.
+from plexora._resources import configure_thread_pools
+
+configure_thread_pools()
 
 # Where data lives is `plexora.paths`' business, and it is resolved on demand
 # rather than here. This module used to compute `data_path` at import, whose
@@ -29,6 +42,43 @@ from plexora._url import clean_prefix as _clean_base_url
 #: Where the entry URL's `?token=` is remembered for the rest of the session.
 AUTH_COOKIE = "plexora_auth"
 
+#: What the unavailable-resource handler has already said, and the load it said
+#: it for. One screenful of the viewer is dozens of tile requests and every one
+#: of them fails the same way against the same absent machine, so the sentence
+#: is printed once and the rest are quiet.
+_said_unavailable = set()
+_said_for_generation = None
+_said_lock = threading.Lock()
+
+
+def _say_unavailable_once(message, context=""):
+    """Print `message` unless this load of a project has already printed it.
+
+    Keyed on `data_model.load_generation` rather than cleared on a timer:
+    reloading is the only thing that re-reads a project's bindings, so it is
+    exactly when "is that node here" can have a different answer -- which is
+    the same reason the tile cache keys on it.
+
+    `context` rides along on the line without joining the key, so the line
+    names one of the requests that hit this rather than standing for none of
+    them.
+    """
+    global _said_for_generation
+
+    # Local, like every other import of the server package in this module: it
+    # imports this one back, and this runs long after both are built anyway.
+    from plexora.server.models import data_model
+
+    with _said_lock:
+        if data_model.load_generation != _said_for_generation:
+            _said_for_generation = data_model.load_generation
+            _said_unavailable.clear()
+        if message in _said_unavailable:
+            return
+        _said_unavailable.add(message)
+    print(f"{context} -- {message}" if context else message)
+
+
 app = None
 
 
@@ -134,10 +184,35 @@ def create_app(plugins=None):
         # cannot read out of an HttpOnly cookie.
         return response
 
+    # The one failure the provider layer is built to survive, answered as one.
+    #
+    # `ResourceUnavailable` means a machine did not answer -- a laptop asleep, a
+    # tunnel dropped, a compute job ended, a node disconnected -- and it arrives
+    # already carrying the sentence its owner should read. Unhandled, Flask
+    # called that a 500 and logged the whole traceback, and since the viewer
+    # asks for one tile at a time, a single screenful of a project on a vanished
+    # node buried the terminal in dozens of identical stacks. None of it was
+    # news: the node is named in the first line, and `/resource_status` has
+    # already put the same sentence on screen with the button that fixes it.
+    #
+    # 503 rather than 500 because the condition is temporary by definition, and
+    # rather than 404 because the resource has not gone -- the road to it has.
+    # The answer is JSON because only routes that read data can arrive here;
+    # rendering a page touches no resource.
+    from plexora.server.providers.base import ResourceUnavailable
+
+    @app.errorhandler(ResourceUnavailable)
+    def resource_unavailable(exc):
+        # The path goes in the line but not in the key: one request stands for
+        # the screenful, and keying on it would print every one of them.
+        _say_unavailable_once(str(exc), f"{request.method} {request.path}")
+        return jsonify(success=False, error=str(exc), node=exc.node,
+                       unavailable=True), 503
+
     # Imported here (not at module top) purely for their route-registration
     # side effects -- see the docstring above for why `app` must already be
     # assigned by this point.
-    from plexora.server.routes import page_routes, data_routes, import_routes, quick_view_routes, browse_routes, tool_routes, system_routes, project_routes
+    from plexora.server.routes import page_routes, data_routes, import_routes, quick_view_routes, browse_routes, transfer_routes, tool_routes, system_routes, project_routes, settings_routes
     from plexora.server.models import data_model, database_model
     from plexora.server import plugins as plugin_registry
 

plexora-0.0.7/plexora/_resources.py

@@ -0,0 +1,236 @@
+"""How much CPU this process actually has, and everything sized from it.
+
+One number, computed once, feeding three decisions that used to be made
+independently and wrongly:
+
+- how many threads the numeric stack (BLAS/OpenMP, blosc) may start,
+- how many request workers waitress runs,
+- how many requests the page may have in flight while restoring channels.
+
+The reason this module exists is that **`os.cpu_count()` is the wrong question
+on a cluster**. It reports the machine's cores, not the allocation's. A SLURM
+job asking for `--cpus-per-task=2` on a 64-core node still sees 64 there, so
+OpenBLAS starts 64 threads, numcodecs starts 8 decompression threads, and all
+of them contend for two cores' worth of quota. Measured on HMS O2, that
+oversubscription is what turned "opening a project is slow" into a task queue
+that never drained and a reverse proxy returning 502.
+
+There is no single reliable signal, so this takes the minimum of the ones that
+exist, each of which is authoritative when present:
+
+- `sched_getaffinity` -- right when the site pins jobs with a cpuset. Silent
+  (reports every core) when the site uses CPU *quota* instead.
+- the cgroup CPU quota -- right in exactly the case affinity is silent.
+- `SLURM_CPUS_PER_TASK` -- what was actually requested, and the only signal
+  that survives a site configuring neither of the above.
+
+Deliberately a leaf module: stdlib only, imports nothing from `plexora`, so
+`plexora/__init__.py` can call it before anything numeric is imported.
+"""
+
+from __future__ import annotations
+
+import os
+
+#: Never fewer than this many request workers, whatever the allocation. A
+#: single-core allocation still needs enough workers that a blocked tile read
+#: cannot starve /health -- the liveness probe does no work at all, and a page
+#: that cannot reach it reports the server as dead while it is merely busy.
+MIN_WORKER_THREADS = 8
+
+#: Above this, more workers only add concurrent full-resolution reads to hold
+#: in memory. All image I/O is serialized downstream anyway (see data_model's
+#: note on the zarr io thread and tifffile's per-file read lock), so the extra
+#: workers would queue on that lock rather than do useful work.
+MAX_WORKER_THREADS = 32
+
+#: The page never fans out wider than this even on a large node. Past roughly
+#: this point the restore burst is bounded by the serialized reader rather than
+#: by the client, and a wider burst just moves the queue from the browser into
+#: waitress where it is harder to see.
+MAX_CLIENT_CONCURRENCY = 8
+
+#: Floor for the same, so a one- or two-core allocation still overlaps a little
+#: rather than restoring strictly one channel at a time.
+MIN_CLIENT_CONCURRENCY = 2
+
+
+def _affinity_cpus():
+    """Cores this process may be scheduled on, or None where unsupported.
+
+    Absent on macOS and Windows, which is why every caller has to tolerate None
+    rather than treating it as the answer.
+    """
+    getaffinity = getattr(os, "sched_getaffinity", None)
+    if getaffinity is None:
+        return None
+    try:
+        count = len(getaffinity(0))
+    except OSError:
+        return None
+    return count or None
+
+
+def _cgroup_cpus():
+    """Cores implied by the cgroup CPU quota, or None when unlimited/absent.
+
+    This is the signal that catches a site using `cpu.max` quota without a
+    cpuset: affinity reports the whole node, and only the quota knows the job
+    was given two cores. Both cgroup versions are read because clusters run
+    both, and a wrong answer here is worse than no answer -- so anything
+    unparseable returns None and lets another signal decide.
+    """
+    # cgroup v2: "<quota> <period>", or "max <period>" when unlimited.
+    try:
+        quota_text, period_text = _read_text("/sys/fs/cgroup/cpu.max").split()
+        if quota_text != "max":
+            return _quota_to_cpus(int(quota_text), int(period_text))
+    except (OSError, ValueError):
+        pass
+
+    # cgroup v1: the two halves live in separate files, and a quota of -1
+    # means unlimited.
+    try:
+        quota = int(_read_text("/sys/fs/cgroup/cpu/cpu.cfs_quota_us"))
+        period = int(_read_text("/sys/fs/cgroup/cpu/cpu.cfs_period_us"))
+        if quota > 0:
+            return _quota_to_cpus(quota, period)
+    except (OSError, ValueError):
+        pass
+
+    return None
+
+
+def _read_text(path):
+    with open(path, "r", encoding="utf-8") as handle:
+        return handle.read().strip()
+
+
+def _quota_to_cpus(quota, period):
+    """Whole cores a quota/period pair is worth, rounded up, minimum 1.
+
+    Rounded UP rather than down because a fractional allocation (say 1.5 cores)
+    still benefits from two threads: one of them is usually blocked on I/O, and
+    rounding down to 1 would serialize work the quota can genuinely overlap.
+    """
+    if period <= 0:
+        return None
+    return max(1, -(-quota // period))
+
+
+def _scheduler_cpus():
+    """What the batch scheduler was asked for, or None outside a job.
+
+    Last of the three signals and the crudest, but it is the only one that
+    survives a site configuring neither cpuset nor quota -- which does happen,
+    and is precisely the configuration where the other two lie by reporting the
+    whole node.
+
+    Scheduler variables only. `OMP_NUM_THREADS` looks like it belongs here and
+    does not: it states a thread-pool preference rather than an allocation, and
+    `configure_thread_pools` sets it -- so reading it back would make this
+    function's own output one of its own inputs.
+    """
+    for name in ("SLURM_CPUS_PER_TASK", "SLURM_CPUS_ON_NODE",
+                 "PBS_NP", "NSLOTS"):
+        raw = os.environ.get(name)
+        if not raw:
+            continue
+        try:
+            value = int(str(raw).strip())
+        except ValueError:
+            continue
+        if value > 0:
+            return value
+    return None
+
+
+def allocated_cpus():
+    """Cores this process can actually use. Never zero.
+
+    The minimum of every signal that answered, because each one is right in a
+    situation where the others are silent, and a signal that is silent reports
+    the whole machine rather than admitting it does not know. Taking the
+    minimum is therefore the only combination that cannot over-subscribe.
+    """
+    candidates = [value for value in (_affinity_cpus(), _cgroup_cpus(),
+                                      _scheduler_cpus(), os.cpu_count())
+                  if value]
+    return max(1, min(candidates)) if candidates else 1
+
+
+def worker_threads():
+    """How many request workers waitress should run.
+
+    Deliberately NOT equal to the core count. Most workers spend their time
+    blocked on the serialized image reader rather than computing, so more of
+    them than cores is both harmless and necessary -- it is what keeps a worker
+    free to answer /health while the rest wait.
+    """
+    return max(MIN_WORKER_THREADS, min(allocated_cpus() * 2, MAX_WORKER_THREADS))
+
+
+def client_concurrency():
+    """How many requests the page may have in flight restoring channels.
+
+    Sized from cores rather than from workers because each of these requests
+    does real per-channel work at the far end, and one worker short of the pool
+    is reserved so the liveness probe is always answerable.
+    """
+    ceiling = min(allocated_cpus(), worker_threads() - 1, MAX_CLIENT_CONCURRENCY)
+    return max(MIN_CLIENT_CONCURRENCY, ceiling)
+
+
+def configure_thread_pools(cpus=None):
+    """Cap every numeric thread pool at the allocation. Returns the cap used.
+
+    Belt AND braces, because the two mechanisms cover different cases and
+    neither covers both:
+
+    - The environment variables are read by OpenBLAS/MKL/OpenMP when they are
+      first loaded, so they work only if nothing numeric has been imported
+      yet. That is the sidecar's situation (`plexora.server_cli` imports this
+      package before anything else) but not the notebook's, where the user may
+      well have imported numpy in an earlier cell.
+    - `threadpool_limits` reaches into already-loaded libraries and is the only
+      thing that helps in the notebook case. It cannot help with blosc, which
+      is not a BLAS-like pool and has to be set through numcodecs.
+
+    Every step is individually guarded: a capped pool is an optimisation, and
+    failing to apply one must never stop the server starting.
+    """
+    cpus = allocated_cpus() if cpus is None else max(1, int(cpus))
+    value = str(cpus)
+
+    # setdefault, not assignment: an operator who exported OMP_NUM_THREADS
+    # meant it, and silently overriding them would be the same class of bug
+    # this module exists to fix.
+    for name in ("OMP_NUM_THREADS", "OPENBLAS_NUM_THREADS", "MKL_NUM_THREADS",
+                 "NUMEXPR_NUM_THREADS", "VECLIB_MAXIMUM_THREADS",
+                 "BLIS_NUM_THREADS"):
+        os.environ.setdefault(name, value)
+
+    try:
+        from threadpoolctl import threadpool_limits
+
+        # Called for its side effect and the result deliberately dropped:
+        # `threadpool_limits` restores the previous limits on __exit__ or an
+        # explicit restore, never on garbage collection, so a bare call sets
+        # the cap for the life of the process. This is also the fix for the
+        # call this replaced, which passed no limits at all and therefore
+        # capped nothing -- it only ever forced the BLAS libraries to load.
+        threadpool_limits(limits=cpus)
+    except Exception:
+        pass
+
+    try:
+        # zarr's decompression pool, and the one signal that is definitely
+        # wrong by default: numcodecs sizes it from the machine's core count,
+        # so a 2-core allocation still gets 8 decompression threads.
+        import numcodecs.blosc
+
+        numcodecs.blosc.set_nthreads(cpus)
+    except Exception:
+        pass
+
+    return cpus

{plexora-0.0.2 → plexora-0.0.7}/plexora/api/__init__.py

@@ -32,6 +32,12 @@ from plexora.api.dataset import (
 from plexora.api.http import json_response
 from plexora.api.store import PluginStore, store
 from plexora.server.models.adapters.anndata_adapter import _deduplicate_names
+from plexora.server.providers.base import (
+    ResourceLocator,
+    ResourceNotLocal,
+    ResourceUnavailable,
+)
+from plexora.server.providers.operations import table_operation, table_stream
 
 #: Multiplexed panels routinely re-stain the same marker across cycles, so
 #: duplicate names are ordinary rather than exceptional. Suffixes them the way
@@ -45,6 +51,9 @@ __all__ = [
     "ImageSource",
     "MetadataColumn",
     "PluginStore",
+    "ResourceLocator",
+    "ResourceNotLocal",
+    "ResourceUnavailable",
     "SegHandle",
     "TableHandle",
     "TableSource",
@@ -52,4 +61,6 @@ __all__ = [
     "deduplicate_names",
     "json_response",
     "store",
+    "table_operation",
+    "table_stream",
 ]