Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

Secondary suppressions are lost when `split_tab = TRUE`

未关闭
#68 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
48/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
r
领域
backend, databases

调研方向

Start by reading tab_multi_manager() and the tab_rtauargus2() split branch, especially where split results are merged and the final suppression pattern is selected. Reproduce the provided example with split_tab = TRUE, then reverse the table order and inspect the intermediate column names. Done means primary and secondary suppressions are preserved in the returned tables regardless of input order, with regression coverage for repeated manager treatments.

由索引模型根据 Issue 内容生成。

描述

bug

Description

When split_tab = TRUE, tab_multi_manager() can silently drop secondary suppressions from the returned tables. The issue appears to depend on the order in which tables are processed.

In the example below, τ-Argus subtable logs report secondary suppressions, but these are not all reflected in the returned master table. Reversing the order of the input tables changes which table is affected, despite the underlying data remaining unchanged.

Steps to reproduce

library(rtauargus)
library(dplyr)

data("datatest2")

v <- names(datatest2)[1:5]

agg <- function(keep) {
  datatest2 |>
    summarise(
      pizzas_tot_abs = sum(pizzas_tot_abs),
      nb_obs_rnd = sum(nb_obs_rnd),
      .by = all_of(keep)
    ) |>
    mutate(is_secret_prim = nb_obs_rnd > 0 & nb_obs_rnd < 5)
}

t1 <- agg(v[1:4])
t2 <- agg(v[c(1:3, 5)])

res <- tab_multi_manager(
  list_tables = list(t1 = t1, t2 = t2),
  list_explanatory_vars = list(t1 = v[1:4], t2 = v[c(1:3, 5)]),
  dir_name = "tauargus_files",
  value = "pizzas_tot_abs",
  freq = "nb_obs_rnd",
  secret_var = "is_secret_prim",
  totcode = "Total",
  split_tab = TRUE
)

sapply(res, function(r) {
  fin <- as.logical(r[[ncol(r)]])
  prim <- as.logical(r$is_secret_prim)

  c(
    primaries = sum(prim),
    secondaries = sum(fin & !prim, na.rm = TRUE)
  )
})

Reversing the order of t1 and t2 in list_tables and list_explanatory_vars changes which table exhibits the problem.

Observed behavior

  • τ-Argus subtable logs report secondary suppressions that are missing from the returned master table.
  • The issue appears on subsequent manager treatments, when a previously generated suppression-pattern column is reused as secret_var.
  • The affected table depends on the processing order.
  • The problem appears to be specific to the split-table processing path.

For example, in one run, the logs for t2 report the following counts for its two subtables across three manager passes:

  • t2_1.txt: 243, 33, 2
  • t2_2.txt: 186, 14, 2

However, the returned master table does not retain all the secondary suppressions reported by τ-Argus.

Suspected cause

Two interacting issues may explain the behavior.

1. Column-name collision in the split path

During subsequent manager treatments, tab_multi_manager() passes a previously generated column as secret_var, for example is_secret_1.

The split runner also generates an iteration column with that name. When the results are merged, duplicate names can be disambiguated using suffixes such as .x and .y. The original input suppression indicator may then be appended as the last column, after the genuine final suppression pattern.

For example, the returned data frame may contain columns resembling:

value
freq
is_secret_1.x
is_secret_1.y
is_secret_2
is_secret_3
is_secret_4
is_secret_1

Consequently, the final column may no longer represent the final suppression pattern.

2. The final suppression pattern is inferred positionally

In tab_rtauargus2, the split branch identifies the final pattern using the last column:

last_iteration <- names(res)[length(names(res))]

res$Status <- ifelse(
  res[[secret_var]], "B",
  ifelse(res[[last_iteration]], "D", "V")
)

If the last column is the re-appended a priori suppression indicator rather than the genuine final pattern, secondary suppressions are incorrectly classified as visible. The secondary suppressions computed by τ-Argus are therefore silently discarded from the returned result.

This suspected mechanism should be confirmed by inspecting the merged intermediate data frame in a failing run.

Expected behavior

  • All primary and secondary suppressions calculated by τ-Argus should be preserved in the returned master table.
  • The result should not depend on the order in which the input tables are supplied.
  • The final suppression pattern should be identified reliably, including when split_tab = TRUE and multiple manager treatments are performed.

Suggested fix

Avoid identifying the final suppression pattern solely by its position in the data frame.

Possible approaches include:

  1. Explicitly track the name of the final iteration column generated by the split runner.
  2. Rename the incoming a priori suppression indicator to a reserved name, such as is_secret_apriori, before splitting to prevent collisions with generated is_secret_<n> columns.
  3. Select the final pattern from the columns generated during the current call, rather than assuming the last column is the final pattern.

Explicit tracking of generated iteration columns would be the most robust approach.

Regression tests

Add tests covering the following cases:

  • split_tab = TRUE with at least two tables.
  • Reversing the order of the input tables must not change the correctness of the suppression results.
  • Multiple manager treatments, where a previously generated suppression-pattern column is passed as secret_var.
  • Verification that the secondary suppressions in the returned master table are consistent with the final suppression patterns reported by τ-Argus.
主要语言
HTML
星标
12
派生
6
平均合并
36 分钟
30 天内合并 PR
1

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南,环境需要你自己搭建:先看它的 README,通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

InseeFrLab/rtauargus 的其他 Issue

查看 InseeFrLab/rtauargus 的全部 Issue

相似的 Issue

更多 Backend & API Design Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。