Skip to content

[finding] an RLS denial caused by an unresolved variable logs NOTHING and explain reports it as narrows rather than denies — the operator debugging "this user sees no rows" gets no signal #13639

Closed
Bug
#13960
Closed
[finding] an RLS denial caused by an unresolved variable logs NOTHING and explain reports it as narrows rather than denies — the operator debugging "this user sees no rows" gets no signal#13639
Bug
#13960
Assignees
os-steve
Labels
bugSomething isn't workingdomain:servicespriority:p2Medium: important, M3

Description

@zhuangjianguo
zhuangjianguo
opened on Aug 31, 2026

Filed by the domain:engine lane PM, from a measurement made during the clause ② contract review of PR #13630 (#13496). Recording only — no severity asserted, routing is triage's.

⚠️PRE-EXISTING and low-urgency. This is the observability of the long-standing scalar "no active org" fail-closed path. PR #13630 neither introduced nor degraded it — that PR was measured to inherit this behaviour, which is why it was accepted rather than held. Ranking it is triage's; I am filing it because it now has a precise measurement and would otherwise be lost with the review thread.

Measured, at 1cdf3c14ef

When compileCelToFilter refuses (a current_user.* variable resolving to null/undefined, and now also a null MEMBER of a membership array), the compiler produces a useful detail — "unresolved member at index N", naming the variable path. Three things then happen to it:

stagewhat happens
plugin-security/rls-compiler.ts:343the detail is discarded — only !ok is consumed
the drop-warn beside itgated on !isSupportedRlsExpression, which is true for membership shapes ⇒ nothing logs
explainreports the sentinel with verdict narrows, not denies — its isDenyAll matches only its own __deny_all__, never __rls_deny__

So the denial is real and correct — record attribution excludes properly, and __rls_deny__is visible in readFilter — but the reason is thrown away at the one place that could surface it, and the one diagnostic tool that exists mislabels the outcome.

Why it matters more than an ordinary missing log

The failure mode this produces is the worst-shaped one for an operator: a user sees zero rows, no error is raised, nothing appears in the log, and the built-in explanation tool says the policy "narrows" rather than "denies". Every signal available points away from the actual cause.

⭐ And the denial is deliberate — it is the fail-closed path working as designed. That is exactly why it needs a trace: a correct refusal that is indistinguishable from "the data genuinely doesn't match" costs an operator hours, and the information needed to end that search was computed and then dropped one line before it could be used.

Scope NOT established

  • ⛔ Whether other !ok consumers discard the same detail is unmeasured — I checked this one path.
  • ⛔ Whether explain's isDenyAll should recognise __rls_deny__, or whether the two sentinels are deliberately distinct, is a design question I am not answering.
  • ⛔ No claim that an operator has been bitten. What is measured is that the signal does not exist.

Suggested shape, not a prescription

Two candidates, both small, neither costed here: surface the discarded detail at the drop site (the warn is already there, only mis-gated), and/or teach explain's isDenyAll about __rls_deny__. Which, and whether either is worth doing now, is triage's and the maintainer's.

Related

#13496 / PR #13630 (where the clause ② review measured it) · #13552 (the polarity-blind deny guard on the same seam) · ADR-0056 / ADR-0058

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingdomain:servicespriority:p2Medium: important, M3

Type

Bug

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    , 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all 
     blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
[finding] an RLS denial caused by an unresolved variable logs NOTHING and `explain` reports it as `narrows` rather than `denies` — the operator debugging "this user sees no rows" gets no signal · Issue #13639 · objectstack-ai/objectstack · GitHub
    Skip to content
    [finding] an RLS denial caused by an unresolved variable logs NOTHING and explain reports it as narrows rather than denies — the operator debugging "this user sees no rows" gets no signal #13639
    Closed
    Bug
    #13960
    Closed
    [finding] an RLS denial caused by an unresolved variable logs NOTHING and explain reports it as narrows rather than denies — the operator debugging "this user sees no rows" gets no signal#13639
    Bug
    #13960
    Assignees
    os-steve
    Labels
    bugSomething isn't workingdomain:servicespriority:p2Medium: important, M3
    Description
    @zhuangjianguo
    zhuangjianguo
    opened on Aug 31, 2026
    Filed by the domain:engine lane PM, from a measurement made during the clause ② contract review of PR #13630 (#13496). Recording only — no severity asserted, routing is triage's.
    ⚠️PRE-EXISTING and low-urgency. This is the observability of the long-standing scalar "no active org" fail-closed path. PR #13630 neither introduced nor degraded it — that PR was measured to inherit this behaviour, which is why it was accepted rather than held. Ranking it is triage's; I am filing it because it now has a precise measurement and would otherwise be lost with the review thread.
    Measured, at 1cdf3c14ef
    When compileCelToFilter refuses (a current_user.* variable resolving to null/undefined, and now also a null MEMBER of a membership array), the compiler produces a useful detail — "unresolved member at index N", naming the variable path. Three things then happen to it:
    stagewhat happens
    plugin-security/rls-compiler.ts:343the detail is discarded — only !ok is consumed
    the drop-warn beside itgated on !isSupportedRlsExpression, which is true for membership shapes ⇒ nothing logs
    explainreports the sentinel with verdict narrows, not denies — its isDenyAll matches only its own __deny_all__, never __rls_deny__
    So the denial is real and correct — record attribution excludes properly, and __rls_deny__is visible in readFilter — but the reason is thrown away at the one place that could surface it, and the one diagnostic tool that exists mislabels the outcome.
    Why it matters more than an ordinary missing log
    The failure mode this produces is the worst-shaped one for an operator: a user sees zero rows, no error is raised, nothing appears in the log, and the built-in explanation tool says the policy "narrows" rather than "denies". Every signal available points away from the actual cause.
    ⭐ And the denial is deliberate — it is the fail-closed path working as designed. That is exactly why it needs a trace: a correct refusal that is indistinguishable from "the data genuinely doesn't match" costs an operator hours, and the information needed to end that search was computed and then dropped one line before it could be used.
    Scope NOT established
    • ⛔ Whether other !ok consumers discard the same detail is unmeasured — I checked this one path.
    • ⛔ Whether explain's isDenyAll should recognise __rls_deny__, or whether the two sentinels are deliberately distinct, is a design question I am not answering.
    • ⛔ No claim that an operator has been bitten. What is measured is that the signal does not exist.
    Suggested shape, not a prescription
    Two candidates, both small, neither costed here: surface the discarded detail at the drop site (the warn is already there, only mis-gated), and/or teach explain's isDenyAll about __rls_deny__. Which, and whether either is worth doing now, is triage's and the maintainer's.
    Related
    #13496 / PR #13630 (where the clause ② review measured it) · #13552 (the polarity-blind deny guard on the same seam) · ADR-0056 / ADR-0058
    Metadata
    Metadata
    Assignees
    Labels
    bugSomething isn't workingdomain:servicespriority:p2Medium: important, M3
    Type
    Bug
    Projects
    No projects
      Milestone
      No milestone
      Relationships
      None yet
      Development
      No branches or pull requests
      Issue actions
      
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
[finding] an RLS denial caused by an unresolved variable logs NOTHING and `explain` reports it as `narrows` rather than `denies` — the operator debugging "this user sees no rows" gets no signal · Issue #13639 · objectstack-ai/objectstack · GitHub
      Skip to content
      [finding] an RLS denial caused by an unresolved variable logs NOTHING and explain reports it as narrows rather than denies — the operator debugging "this user sees no rows" gets no signal #13639
      Closed
      Bug
      #13960
      Closed
      [finding] an RLS denial caused by an unresolved variable logs NOTHING and explain reports it as narrows rather than denies — the operator debugging "this user sees no rows" gets no signal#13639
      Bug
      #13960
      Assignees
      os-steve
      Labels
      bugSomething isn't workingdomain:servicespriority:p2Medium: important, M3
      Description
      @zhuangjianguo
      zhuangjianguo
      opened on Aug 31, 2026
      Filed by the domain:engine lane PM, from a measurement made during the clause ② contract review of PR #13630 (#13496). Recording only — no severity asserted, routing is triage's.
      ⚠️PRE-EXISTING and low-urgency. This is the observability of the long-standing scalar "no active org" fail-closed path. PR #13630 neither introduced nor degraded it — that PR was measured to inherit this behaviour, which is why it was accepted rather than held. Ranking it is triage's; I am filing it because it now has a precise measurement and would otherwise be lost with the review thread.
      Measured, at 1cdf3c14ef
      When compileCelToFilter refuses (a current_user.* variable resolving to null/undefined, and now also a null MEMBER of a membership array), the compiler produces a useful detail — "unresolved member at index N", naming the variable path. Three things then happen to it:
      stagewhat happens
      plugin-security/rls-compiler.ts:343the detail is discarded — only !ok is consumed
      the drop-warn beside itgated on !isSupportedRlsExpression, which is true for membership shapes ⇒ nothing logs
      explainreports the sentinel with verdict narrows, not denies — its isDenyAll matches only its own __deny_all__, never __rls_deny__
      So the denial is real and correct — record attribution excludes properly, and __rls_deny__is visible in readFilter — but the reason is thrown away at the one place that could surface it, and the one diagnostic tool that exists mislabels the outcome.
      Why it matters more than an ordinary missing log
      The failure mode this produces is the worst-shaped one for an operator: a user sees zero rows, no error is raised, nothing appears in the log, and the built-in explanation tool says the policy "narrows" rather than "denies". Every signal available points away from the actual cause.
      ⭐ And the denial is deliberate — it is the fail-closed path working as designed. That is exactly why it needs a trace: a correct refusal that is indistinguishable from "the data genuinely doesn't match" costs an operator hours, and the information needed to end that search was computed and then dropped one line before it could be used.
      Scope NOT established
      • ⛔ Whether other !ok consumers discard the same detail is unmeasured — I checked this one path.
      • ⛔ Whether explain's isDenyAll should recognise __rls_deny__, or whether the two sentinels are deliberately distinct, is a design question I am not answering.
      • ⛔ No claim that an operator has been bitten. What is measured is that the signal does not exist.
      Suggested shape, not a prescription
      Two candidates, both small, neither costed here: surface the discarded detail at the drop site (the warn is already there, only mis-gated), and/or teach explain's isDenyAll about __rls_deny__. Which, and whether either is worth doing now, is triage's and the maintainer's.
      Related
      #13496 / PR #13630 (where the clause ② review measured it) · #13552 (the polarity-blind deny guard on the same seam) · ADR-0056 / ADR-0058
      Metadata
      Metadata
      Assignees
      Labels
      bugSomething isn't workingdomain:servicespriority:p2Medium: important, M3
      Type
      Bug
      Projects
      No projects
        Milestone
        No milestone
        Relationships
        None yet
        Development
        No branches or pull requests
        Issue actions
        
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Highlight search terms from Google/DuckDuckGo/Bing referrer
(function() {
var ref = document.referrer;
var terms = [];
if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {
var url = new URL(ref);
var q = url.searchParams.get('q') || url.searchParams.get('p');
if (q) {
terms = q.split(/\s+/).filter(function(t) { return t.length > 2; });
}
}
if (terms.length === 0) return;
var style = document.createElement('style');
style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';
document.head.appendChild(style);
function highlight(node) {
if (node.nodeType === 3) { // text node
var text = node.textContent;
var found = false;
terms.forEach(function(term) {
var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi');
if (regex.test(text)) {
found = true;
var frag = document.createDocumentFragment();
var parts = text.split(regex);
parts.forEach(function(part, i) {
if (i % 2 === 0) {
frag.appendChild(document.createTextNode(part));
} else {
var span = document.createElement('span');
span.className = 'userscript-highlight';
span.textContent = part;
frag.appendChild(span);
}
});
node.parentNode.replaceChild(frag, node);
}
});
} else if (node.nodeType === 1 && node.childNodes) { // element
var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];
if (!skipTags.includes(node.tagName)) {
Array.from(node.childNodes).forEach(highlight);
}
}
}
highlight(document.body);
// Re-highlight on dynamic content
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1 || node.nodeType === 3) highlight(node);
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
[finding] an RLS denial caused by an unresolved variable logs NOTHING and `explain` reports it as `narrows` rather than `denies` — the operator debugging "this user sees no rows" gets no signal · Issue #13639 · objectstack-ai/objectstack · GitHub
        Skip to content
        [finding] an RLS denial caused by an unresolved variable logs NOTHING and explain reports it as narrows rather than denies — the operator debugging "this user sees no rows" gets no signal #13639
        Closed
        Bug
        #13960
        Closed
        [finding] an RLS denial caused by an unresolved variable logs NOTHING and explain reports it as narrows rather than denies — the operator debugging "this user sees no rows" gets no signal#13639
        Bug
        #13960
        Assignees
        os-steve
        Labels
        bugSomething isn't workingdomain:servicespriority:p2Medium: important, M3
        Description
        @zhuangjianguo
        zhuangjianguo
        opened on Aug 31, 2026
        Filed by the domain:engine lane PM, from a measurement made during the clause ② contract review of PR #13630 (#13496). Recording only — no severity asserted, routing is triage's.
        ⚠️PRE-EXISTING and low-urgency. This is the observability of the long-standing scalar "no active org" fail-closed path. PR #13630 neither introduced nor degraded it — that PR was measured to inherit this behaviour, which is why it was accepted rather than held. Ranking it is triage's; I am filing it because it now has a precise measurement and would otherwise be lost with the review thread.
        Measured, at 1cdf3c14ef
        When compileCelToFilter refuses (a current_user.* variable resolving to null/undefined, and now also a null MEMBER of a membership array), the compiler produces a useful detail — "unresolved member at index N", naming the variable path. Three things then happen to it:
        stagewhat happens
        plugin-security/rls-compiler.ts:343the detail is discarded — only !ok is consumed
        the drop-warn beside itgated on !isSupportedRlsExpression, which is true for membership shapes ⇒ nothing logs
        explainreports the sentinel with verdict narrows, not denies — its isDenyAll matches only its own __deny_all__, never __rls_deny__
        So the denial is real and correct — record attribution excludes properly, and __rls_deny__is visible in readFilter — but the reason is thrown away at the one place that could surface it, and the one diagnostic tool that exists mislabels the outcome.
        Why it matters more than an ordinary missing log
        The failure mode this produces is the worst-shaped one for an operator: a user sees zero rows, no error is raised, nothing appears in the log, and the built-in explanation tool says the policy "narrows" rather than "denies". Every signal available points away from the actual cause.
        ⭐ And the denial is deliberate — it is the fail-closed path working as designed. That is exactly why it needs a trace: a correct refusal that is indistinguishable from "the data genuinely doesn't match" costs an operator hours, and the information needed to end that search was computed and then dropped one line before it could be used.
        Scope NOT established
        • ⛔ Whether other !ok consumers discard the same detail is unmeasured — I checked this one path.
        • ⛔ Whether explain's isDenyAll should recognise __rls_deny__, or whether the two sentinels are deliberately distinct, is a design question I am not answering.
        • ⛔ No claim that an operator has been bitten. What is measured is that the signal does not exist.
        Suggested shape, not a prescription
        Two candidates, both small, neither costed here: surface the discarded detail at the drop site (the warn is already there, only mis-gated), and/or teach explain's isDenyAll about __rls_deny__. Which, and whether either is worth doing now, is triage's and the maintainer's.
        Related
        #13496 / PR #13630 (where the clause ② review measured it) · #13552 (the polarity-blind deny guard on the same seam) · ADR-0056 / ADR-0058
        Metadata
        Metadata
        Assignees
        Labels
        bugSomething isn't workingdomain:servicespriority:p2Medium: important, M3
        Type
        Bug
        Projects
        No projects
          Milestone
          No milestone
          Relationships
          None yet
          Development
          No branches or pull requests
          Issue actions
          
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '
[finding] an RLS denial caused by an unresolved variable logs NOTHING and `explain` reports it as `narrows` rather than `denies` — the operator debugging "this user sees no rows" gets no signal · Issue #13639 · objectstack-ai/objectstack · GitHub
          Skip to content
          [finding] an RLS denial caused by an unresolved variable logs NOTHING and explain reports it as narrows rather than denies — the operator debugging "this user sees no rows" gets no signal #13639
          Closed
          Bug
          #13960
          Closed
          [finding] an RLS denial caused by an unresolved variable logs NOTHING and explain reports it as narrows rather than denies — the operator debugging "this user sees no rows" gets no signal#13639
          Bug
          #13960
          Assignees
          os-steve
          Labels
          bugSomething isn't workingdomain:servicespriority:p2Medium: important, M3
          Description
          @zhuangjianguo
          zhuangjianguo
          opened on Aug 31, 2026
          Filed by the domain:engine lane PM, from a measurement made during the clause ② contract review of PR #13630 (#13496). Recording only — no severity asserted, routing is triage's.
          ⚠️PRE-EXISTING and low-urgency. This is the observability of the long-standing scalar "no active org" fail-closed path. PR #13630 neither introduced nor degraded it — that PR was measured to inherit this behaviour, which is why it was accepted rather than held. Ranking it is triage's; I am filing it because it now has a precise measurement and would otherwise be lost with the review thread.
          Measured, at 1cdf3c14ef
          When compileCelToFilter refuses (a current_user.* variable resolving to null/undefined, and now also a null MEMBER of a membership array), the compiler produces a useful detail — "unresolved member at index N", naming the variable path. Three things then happen to it:
          stagewhat happens
          plugin-security/rls-compiler.ts:343the detail is discarded — only !ok is consumed
          the drop-warn beside itgated on !isSupportedRlsExpression, which is true for membership shapes ⇒ nothing logs
          explainreports the sentinel with verdict narrows, not denies — its isDenyAll matches only its own __deny_all__, never __rls_deny__
          So the denial is real and correct — record attribution excludes properly, and __rls_deny__is visible in readFilter — but the reason is thrown away at the one place that could surface it, and the one diagnostic tool that exists mislabels the outcome.
          Why it matters more than an ordinary missing log
          The failure mode this produces is the worst-shaped one for an operator: a user sees zero rows, no error is raised, nothing appears in the log, and the built-in explanation tool says the policy "narrows" rather than "denies". Every signal available points away from the actual cause.
          ⭐ And the denial is deliberate — it is the fail-closed path working as designed. That is exactly why it needs a trace: a correct refusal that is indistinguishable from "the data genuinely doesn't match" costs an operator hours, and the information needed to end that search was computed and then dropped one line before it could be used.
          Scope NOT established
          • ⛔ Whether other !ok consumers discard the same detail is unmeasured — I checked this one path.
          • ⛔ Whether explain's isDenyAll should recognise __rls_deny__, or whether the two sentinels are deliberately distinct, is a design question I am not answering.
          • ⛔ No claim that an operator has been bitten. What is measured is that the signal does not exist.
          Suggested shape, not a prescription
          Two candidates, both small, neither costed here: surface the discarded detail at the drop site (the warn is already there, only mis-gated), and/or teach explain's isDenyAll about __rls_deny__. Which, and whether either is worth doing now, is triage's and the maintainer's.
          Related
          #13496 / PR #13630 (where the clause ② review measured it) · #13552 (the polarity-blind deny guard on the same seam) · ADR-0056 / ADR-0058
          Metadata
          Metadata
          Assignees
          Labels
          bugSomething isn't workingdomain:servicespriority:p2Medium: important, M3
          Type
          Bug
          Projects
          No projects
            Milestone
            No milestone
            Relationships
            None yet
            Development
            No branches or pull requests
            Issue actions
            
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
[finding] an RLS denial caused by an unresolved variable logs NOTHING and `explain` reports it as `narrows` rather than `denies` — the operator debugging "this user sees no rows" gets no signal · Issue #13639 · objectstack-ai/objectstack · GitHub
            Skip to content
            [finding] an RLS denial caused by an unresolved variable logs NOTHING and explain reports it as narrows rather than denies — the operator debugging "this user sees no rows" gets no signal #13639
            Closed
            Bug
            #13960
            Closed
            [finding] an RLS denial caused by an unresolved variable logs NOTHING and explain reports it as narrows rather than denies — the operator debugging "this user sees no rows" gets no signal#13639
            Bug
            #13960
            Assignees
            os-steve
            Labels
            bugSomething isn't workingdomain:servicespriority:p2Medium: important, M3
            Description
            @zhuangjianguo
            zhuangjianguo
            opened on Aug 31, 2026
            Filed by the domain:engine lane PM, from a measurement made during the clause ② contract review of PR #13630 (#13496). Recording only — no severity asserted, routing is triage's.
            ⚠️PRE-EXISTING and low-urgency. This is the observability of the long-standing scalar "no active org" fail-closed path. PR #13630 neither introduced nor degraded it — that PR was measured to inherit this behaviour, which is why it was accepted rather than held. Ranking it is triage's; I am filing it because it now has a precise measurement and would otherwise be lost with the review thread.
            Measured, at 1cdf3c14ef
            When compileCelToFilter refuses (a current_user.* variable resolving to null/undefined, and now also a null MEMBER of a membership array), the compiler produces a useful detail — "unresolved member at index N", naming the variable path. Three things then happen to it:
            stagewhat happens
            plugin-security/rls-compiler.ts:343the detail is discarded — only !ok is consumed
            the drop-warn beside itgated on !isSupportedRlsExpression, which is true for membership shapes ⇒ nothing logs
            explainreports the sentinel with verdict narrows, not denies — its isDenyAll matches only its own __deny_all__, never __rls_deny__
            So the denial is real and correct — record attribution excludes properly, and __rls_deny__is visible in readFilter — but the reason is thrown away at the one place that could surface it, and the one diagnostic tool that exists mislabels the outcome.
            Why it matters more than an ordinary missing log
            The failure mode this produces is the worst-shaped one for an operator: a user sees zero rows, no error is raised, nothing appears in the log, and the built-in explanation tool says the policy "narrows" rather than "denies". Every signal available points away from the actual cause.
            ⭐ And the denial is deliberate — it is the fail-closed path working as designed. That is exactly why it needs a trace: a correct refusal that is indistinguishable from "the data genuinely doesn't match" costs an operator hours, and the information needed to end that search was computed and then dropped one line before it could be used.
            Scope NOT established
            • ⛔ Whether other !ok consumers discard the same detail is unmeasured — I checked this one path.
            • ⛔ Whether explain's isDenyAll should recognise __rls_deny__, or whether the two sentinels are deliberately distinct, is a design question I am not answering.
            • ⛔ No claim that an operator has been bitten. What is measured is that the signal does not exist.
            Suggested shape, not a prescription
            Two candidates, both small, neither costed here: surface the discarded detail at the drop site (the warn is already there, only mis-gated), and/or teach explain's isDenyAll about __rls_deny__. Which, and whether either is worth doing now, is triage's and the maintainer's.
            Related
            #13496 / PR #13630 (where the clause ② review measured it) · #13552 (the polarity-blind deny guard on the same seam) · ADR-0056 / ADR-0058
            Metadata
            Metadata
            Assignees
            Labels
            bugSomething isn't workingdomain:servicespriority:p2Medium: important, M3
            Type
            Bug
            Projects
            No projects
              Milestone
              No milestone
              Relationships
              None yet
              Development
              No branches or pull requests
              Issue actions
              
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
[finding] an RLS denial caused by an unresolved variable logs NOTHING and `explain` reports it as `narrows` rather than `denies` — the operator debugging "this user sees no rows" gets no signal · Issue #13639 · objectstack-ai/objectstack · GitHub
              Skip to content
              [finding] an RLS denial caused by an unresolved variable logs NOTHING and explain reports it as narrows rather than denies — the operator debugging "this user sees no rows" gets no signal #13639
              Closed
              Bug
              #13960
              Closed
              [finding] an RLS denial caused by an unresolved variable logs NOTHING and explain reports it as narrows rather than denies — the operator debugging "this user sees no rows" gets no signal#13639
              Bug
              #13960
              Assignees
              os-steve
              Labels
              bugSomething isn't workingdomain:servicespriority:p2Medium: important, M3
              Description
              @zhuangjianguo
              zhuangjianguo
              opened on Aug 31, 2026
              Filed by the domain:engine lane PM, from a measurement made during the clause ② contract review of PR #13630 (#13496). Recording only — no severity asserted, routing is triage's.
              ⚠️PRE-EXISTING and low-urgency. This is the observability of the long-standing scalar "no active org" fail-closed path. PR #13630 neither introduced nor degraded it — that PR was measured to inherit this behaviour, which is why it was accepted rather than held. Ranking it is triage's; I am filing it because it now has a precise measurement and would otherwise be lost with the review thread.
              Measured, at 1cdf3c14ef
              When compileCelToFilter refuses (a current_user.* variable resolving to null/undefined, and now also a null MEMBER of a membership array), the compiler produces a useful detail — "unresolved member at index N", naming the variable path. Three things then happen to it:
              stagewhat happens
              plugin-security/rls-compiler.ts:343the detail is discarded — only !ok is consumed
              the drop-warn beside itgated on !isSupportedRlsExpression, which is true for membership shapes ⇒ nothing logs
              explainreports the sentinel with verdict narrows, not denies — its isDenyAll matches only its own __deny_all__, never __rls_deny__
              So the denial is real and correct — record attribution excludes properly, and __rls_deny__is visible in readFilter — but the reason is thrown away at the one place that could surface it, and the one diagnostic tool that exists mislabels the outcome.
              Why it matters more than an ordinary missing log
              The failure mode this produces is the worst-shaped one for an operator: a user sees zero rows, no error is raised, nothing appears in the log, and the built-in explanation tool says the policy "narrows" rather than "denies". Every signal available points away from the actual cause.
              ⭐ And the denial is deliberate — it is the fail-closed path working as designed. That is exactly why it needs a trace: a correct refusal that is indistinguishable from "the data genuinely doesn't match" costs an operator hours, and the information needed to end that search was computed and then dropped one line before it could be used.
              Scope NOT established
              • ⛔ Whether other !ok consumers discard the same detail is unmeasured — I checked this one path.
              • ⛔ Whether explain's isDenyAll should recognise __rls_deny__, or whether the two sentinels are deliberately distinct, is a design question I am not answering.
              • ⛔ No claim that an operator has been bitten. What is measured is that the signal does not exist.
              Suggested shape, not a prescription
              Two candidates, both small, neither costed here: surface the discarded detail at the drop site (the warn is already there, only mis-gated), and/or teach explain's isDenyAll about __rls_deny__. Which, and whether either is worth doing now, is triage's and the maintainer's.
              Related
              #13496 / PR #13630 (where the clause ② review measured it) · #13552 (the polarity-blind deny guard on the same seam) · ADR-0056 / ADR-0058
              Metadata
              Metadata
              Assignees
              Labels
              bugSomething isn't workingdomain:servicespriority:p2Medium: important, M3
              Type
              Bug
              Projects
              No projects
                Milestone
                No milestone
                Relationships
                None yet
                Development
                No branches or pull requests
                Issue actions
                
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Universal Dark Mode - works on any site
(function() {
var enabled = true;
function applyDarkMode() {
if (!enabled) return;
// Create style element if it doesn't exist
var style = document.getElementById('universal-dark-mode-style');
if (!style) {
style = document.createElement('style');
style.id = 'universal-dark-mode-style';
document.head.appendChild(style);
}
// Dark mode CSS - inverts colors but preserves images/video
style.textContent = '
/* Invert everything except media */
html {
filter: invert(1) hue-rotate(180deg) !important;
background: #1a1a2e !important;
}
/* Restore images, videos, iframes, canvas */
img, video, iframe, canvas, svg, picture, [style*="background-image"] {
filter: invert(1) hue-rotate(180deg) !important;
}
/* Preserve specific elements that should not be inverted */
.no-dark-mode, .no-dark-mode *,
[data-theme="light"], [data-theme="light"],
.ace_editor, .ace_editor *,
.CodeMirror, .CodeMirror *,
.monaco-editor, .monaco-editor *,
.markdown-body pre, .markdown-body pre *,
.highlight, .highlight *,
pre code, pre code * {
filter: none !important;
}
/* Fix common UI elements */
.modal, .popup, .dropdown-menu, .tooltip, .popover {
filter: invert(1) hue-rotate(180deg) !important;
background: #2d2d44 !important;
border-color: #444 !important;
}
/* Scrollbars */
::-webkit-scrollbar { background: #1a1a2e !important; }
::-webkit-scrollbar-thumb { background: #444 !important; }
::-webkit-scrollbar-thumb:hover { background: #555 !important; }
/* Selection */
::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
';
}
function removeDarkMode() {
var style = document.getElementById('universal-dark-mode-style');
if (style) style.remove();
}
// Toggle with Alt+Shift+D
document.addEventListener('keydown', function(e) {
if (e.altKey && e.shiftKey && e.key === 'D') {
e.preventDefault();
enabled = !enabled;
if (enabled) {
applyDarkMode();
console.log('[Universal Dark Mode] Enabled');
} else {
removeDarkMode();
console.log('[Universal Dark Mode] Disabled');
}
}
});
// Apply on load
applyDarkMode();
// Re-apply on dynamic content
var observer = new MutationObserver(function(mutations) {
if (enabled && !document.getElementById('universal-dark-mode-style')) {
applyDarkMode();
}
});
observer.observe(document.head, { childList: true });
console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');
})();
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();
[finding] an RLS denial caused by an unresolved variable logs NOTHING and `explain` reports it as `narrows` rather than `denies` — the operator debugging "this user sees no rows" gets no signal · Issue #13639 · objectstack-ai/objectstack · GitHub
                Skip to content
                [finding] an RLS denial caused by an unresolved variable logs NOTHING and explain reports it as narrows rather than denies — the operator debugging "this user sees no rows" gets no signal #13639
                Closed
                Bug
                #13960
                Closed
                [finding] an RLS denial caused by an unresolved variable logs NOTHING and explain reports it as narrows rather than denies — the operator debugging "this user sees no rows" gets no signal#13639
                Bug
                #13960
                Assignees
                os-steve
                Labels
                bugSomething isn't workingdomain:servicespriority:p2Medium: important, M3
                Description
                @zhuangjianguo
                zhuangjianguo
                opened on Aug 31, 2026
                Filed by the domain:engine lane PM, from a measurement made during the clause ② contract review of PR #13630 (#13496). Recording only — no severity asserted, routing is triage's.
                ⚠️PRE-EXISTING and low-urgency. This is the observability of the long-standing scalar "no active org" fail-closed path. PR #13630 neither introduced nor degraded it — that PR was measured to inherit this behaviour, which is why it was accepted rather than held. Ranking it is triage's; I am filing it because it now has a precise measurement and would otherwise be lost with the review thread.
                Measured, at 1cdf3c14ef
                When compileCelToFilter refuses (a current_user.* variable resolving to null/undefined, and now also a null MEMBER of a membership array), the compiler produces a useful detail — "unresolved member at index N", naming the variable path. Three things then happen to it:
                stagewhat happens
                plugin-security/rls-compiler.ts:343the detail is discarded — only !ok is consumed
                the drop-warn beside itgated on !isSupportedRlsExpression, which is true for membership shapes ⇒ nothing logs
                explainreports the sentinel with verdict narrows, not denies — its isDenyAll matches only its own __deny_all__, never __rls_deny__
                So the denial is real and correct — record attribution excludes properly, and __rls_deny__is visible in readFilter — but the reason is thrown away at the one place that could surface it, and the one diagnostic tool that exists mislabels the outcome.
                Why it matters more than an ordinary missing log
                The failure mode this produces is the worst-shaped one for an operator: a user sees zero rows, no error is raised, nothing appears in the log, and the built-in explanation tool says the policy "narrows" rather than "denies". Every signal available points away from the actual cause.
                ⭐ And the denial is deliberate — it is the fail-closed path working as designed. That is exactly why it needs a trace: a correct refusal that is indistinguishable from "the data genuinely doesn't match" costs an operator hours, and the information needed to end that search was computed and then dropped one line before it could be used.
                Scope NOT established
                • ⛔ Whether other !ok consumers discard the same detail is unmeasured — I checked this one path.
                • ⛔ Whether explain's isDenyAll should recognise __rls_deny__, or whether the two sentinels are deliberately distinct, is a design question I am not answering.
                • ⛔ No claim that an operator has been bitten. What is measured is that the signal does not exist.
                Suggested shape, not a prescription
                Two candidates, both small, neither costed here: surface the discarded detail at the drop site (the warn is already there, only mis-gated), and/or teach explain's isDenyAll about __rls_deny__. Which, and whether either is worth doing now, is triage's and the maintainer's.
                Related
                #13496 / PR #13630 (where the clause ② review measured it) · #13552 (the polarity-blind deny guard on the same seam) · ADR-0056 / ADR-0058
                Metadata
                Metadata
                Assignees
                Labels
                bugSomething isn't workingdomain:servicespriority:p2Medium: important, M3
                Type
                Bug
                Projects
                No projects
                  Milestone
                  No milestone
                  Relationships
                  None yet
                  Development
                  No branches or pull requests
                  Issue actions