av9ash/GitBugs huggingface dataset:
Bug: HBASE-Find-Flaky-Tests job is failing because of can not build docker image
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 24/Apr/20 08:44

{noformat}
06:30:14  Step 3/4 : RUN DEBIAN_FRONTEND=noninteractive apt-get -qq -y update     && DEBIAN_FRONTEND=noninteractive apt-get -qq -y install --no-install-recommends       curl=7.58.0-2ubuntu3.8       python2.7=2.7.17-1~18.04       python-pip=9.0.1-2.3~ubuntu1.18.04.1       python-setuptools=39.0.1-2     && apt-get clean     && rm -rf /var/lib/apt/lists/*
06:30:14   ---> Running in 484963d42320
06:30:23  [91mE: Version '2.7.17-1~18.04' for 'python2.7' was not found
06:30:23  [0mThe command '/bin/sh -c DEBIAN_FRONTEND=noninteractive apt-get -qq -y update     && DEBIAN_FRONTEND=noninteractive apt-get -qq -y install --no-install-recommends       curl=7.58.0-2ubuntu3.8       python2.7=2.7.17-1~18.04       python-pip=9.0.1-2.3~ubuntu1.18.04.1       python-setuptools=39.0.1-2     && apt-get clean     && rm -rf /var/lib/apt/lists/*' returned a non-zero code: 100
{noformat}
Bug: PreCommit build is failing because of can not build docker image
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 24/Apr/20 06:33

{noformat}
06:29:35  Failed in branch yetus general check
06:29:36  + '[' -f /home/jenkins/jenkins-slave/workspace/Base-PreCommit-GitHub-PR_PR-1574@2/yetus-jdk8-hadoop3-check/output/pidfile.txt ']'
06:29:36  + '[' -f /home/jenkins/jenkins-slave/workspace/Base-PreCommit-GitHub-PR_PR-1574@2/yetus-jdk8-hadoop3-check/output/cidfile.txt ']'
06:29:36  + chmod -R u+rxw /home/jenkins/jenkins-slave/workspace/Base-PreCommit-GitHub-PR_PR-1574@2
[Pipeline] dir
06:29:36  Running in /home/jenkins/jenkins-slave/workspace/Base-PreCommit-GitHub-PR_PR-1574@2/yetus-jdk8-hadoop3-check
[Pipeline] {
[Pipeline] deleteDir
06:29:36  [91mE: Version '1:2.17.1-1ubuntu0.6' for 'git' was not found
{noformat}
Bug: Update openjdk-8-jdk version in create-release
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 24/Apr/20 12:37
Affects Version/s: 3.0.0-alpha-1

The create-release script fails with missing openjdk-8-jdk package.

It needs to be updated to openjdk-8-jdk=8u252-b09-1~18.04 version.
Bug: [Flakey Tests] TestSecureExportSnapshot FileNotFoundException
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 11/Apr/20 18:01

Why we writing '/tmp' dir?

{code}
Error Message

org.apache.hadoop.service.ServiceStateException: java.io.FileNotFoundException: File file:/tmp/hadoop-yarn-jenkins/node-attribute/nodeattribute.mirror.writing does not exist

Stacktrace

org.apache.hadoop.yarn.exceptions.YarnRuntimeException: org.apache.hadoop.service.ServiceStateException: java.io.FileNotFoundException: File file:/tmp/hadoop-yarn-jenkins/node-attribute/nodeattribute.mirror.writing does not exist
	at org.apache.hadoop.hbase.snapshot.TestSecureExportSnapshot.setUpBeforeClass(TestSecureExportSnapshot.java:56)
Caused by: org.apache.hadoop.service.ServiceStateException: java.io.FileNotFoundException: File file:/tmp/hadoop-yarn-jenkins/node-attribute/nodeattribute.mirror.writing does not exist
	at org.apache.hadoop.hbase.snapshot.TestSecureExportSnapshot.setUpBeforeClass(TestSecureExportSnapshot.java:56)
Caused by: java.io.FileNotFoundException: File file:/tmp/hadoop-yarn-jenkins/node-attribute/nodeattribute.mirror.writing does not exist
	at org.apache.hadoop.hbase.snapshot.TestSecureExportSnapshot.setUpBeforeClass(TestSecureExportSnapshot.java:56)

{code}
Bug: [Build] Pin rubocop version <= 0.81
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 22/Apr/20 02:45
Affects Version/s: 1.4.13

rubocop 0.82 has been released, which drops Ruby 2.3 support. 

We are still using Ruby 2.3 in the Docker, and the docker build will fail (at least in branch-1).

Similar to AVRO-2807
Bug: Client getting stuck infinitely while connecting to thrift2 server in Secure mode
Status: Open | Priority: Major | Resolution: 
Created: 22/Apr/20 05:37
Affects Version/s: 2.2.3

Tried connecting thrift2 server to test PUT operation from a secure client
to 1.3.x server . It works fine , But when same operation is performed in
2.2.3 server, client is getting stuck infinitely. it's unable to connect to
server  .

    Exception in thread "main" java.security.PrivilegedActionException: 
    org.apache.thrift.transport.TTransportException: java.net.SocketTimeoutException: Read 
    timed out
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.Subject.doAs(Subject.java:422)
        at org.apache.hadoop.hbase.thrift2.GitDemoClient.main(GitDemoClient.java:80)
   Caused by: org.apache.thrift.transport.TTransportException: 
    java.net.SocketTimeoutException: Read timed out
        at org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:129)
        at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
        at 
    org.apache.thrift.transport.TSaslTransport.receiveSaslMessage(TSaslTransport.java:178)
        at org.apache.thrift.transport.TSaslTransport.open(TSaslTransport.java:277)
        at org.apache.thrift.transport.TSaslClientTransport.open(TSaslClientTransport.java:38)
        at org.apache.hadoop.hbase.thrift2.GitDemoClient.run(GitDemoClient.java:117)
        at org.apache.hadoop.hbase.thrift2.GitDemoClient$1.run(GitDemoClient.java:84)
        at org.apache.hadoop.hbase.thrift2.GitDemoClient$1.run(GitDemoClient.java:1)
        ... 3 more
   Caused by: java.net.SocketTimeoutException: Read timed out
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
        at java.net.SocketInputStream.read(SocketInputStream.java:171)
        at java.net.SocketInputStream.read(SocketInputStream.java:141)
        at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
        at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
        at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
        at org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:127)
        ... 10 more


  Getting above exception when timeout has been set at client side.


*References*

https://github.com/apache/hbase/blob/master/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift2/DemoClient.java

https://hbase.apache.org/book.html#hbase.secure.configuration (section
60.4) Client-side Configuration for Secure operation- Thrift Gateway
Bug: Allow that zk NOTEMPTY multi exception is retryable by running in-series
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 20/Apr/20 22:42

It looks like our zk behavior changed slightly on upgrade. In tests on occasion, I see a fail because the zk delete of dir fails because dir is not empty. Or, this flakey type we just ignored in the past (its rare enough -- I'm just seeing it of late because I'm running tests back-to-back on 4 different hardwares). Let me try allowing NOTEMPTY as a retryable. Lets see how it does.

Threw in some debug while at it for other issues I've seen in test.
Bug: [Flakey Tests] Thrift tests (TestThrift?ServerCmdLine)
Status: Open | Priority: Major | Resolution: 
Created: 06/Apr/20 16:19

TestThrift2ServerCmdLine and TestThriftServerCmdLine are flakey. They fail frequently in local runs for myriad reasons: protocol failures, wrong answers on query, connection resets, etc. Each test runs 40 different combinations of config.

This is after work done to try and stabilize by fixing port clash issues.

Let me list in here the ways in which it fails. I will disable after I get a good list. Will also try and do some more stabilization too in sub-issues. Lets see which prevails; stabilization or disabling.

For starters, this morning I got this:

{code}
 -------------------------------------------------------------------------------
 Test set: org.apache.hadoop.hbase.thrift2.TestThrift2ServerCmdLine
 -------------------------------------------------------------------------------
 Tests run: 32, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 126.301 s <<< FAILURE! - in org.apache.hadoop.hbase.thrift2.TestThrift2ServerCmdLine
 org.apache.hadoop.hbase.thrift2.TestThrift2ServerCmdLine.testRunThriftServer[29]  Time elapsed: 0.964 s  <<< ERROR!
 java.lang.Exception: org.apache.thrift.transport.TTransportException: java.net.SocketException: Connection reset
   at org.apache.hadoop.hbase.thrift2.TestThrift2ServerCmdLine.talkToThriftServer(TestThrift2ServerCmdLine.java:92)
 Caused by: java.net.SocketException: Connection reset
   at org.apache.hadoop.hbase.thrift2.TestThrift2ServerCmdLine.talkToThriftServer(TestThrift2ServerCmdLine.java:92)
{code}
Bug: Fix findbugs warning on ServiceAuthorizationManager
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 11/Apr/20 15:24

Inconsistent synchronization of org.apache.hadoop.hbase.ipc.RpcServer.authManager; locked 66% of time.

It is introduced by HBASE-24121, let me fix it. It haven't got released yet. Looks affect branch-1 so far.
Bug: Upgrade Thrift to 0.13.0: 0.12.0 has outstanding CVEs.
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 08/Apr/20 22:02
Affects Version/s: 3.0.0-alpha-1

In Apache Thrift all versions up to and including 0.12.0, a server or client may run into an endless loop when feed with specific input data. Because the issue had already been partially fixed in version 0.11.0, depending on the installed version it affects only certain language bindings.

To be on the safe side, we could update to 0.13.0.
Bug: HRegion#processRowsWithLocks count memstore size wrong when sync failed
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 15/Apr/20 02:23
Affects Version/s: 1.7.0

HRegion#processRowsWithLocks when wal sync failed, it will roll back the memstore in Store and reduce the size in DefaultMemStore, but still add memStoreSize to HRegion#memstoreSize.
And this only affect branch-1 verions, not apply to master/branch-2.
Bug: [Flakey Tests] TestAsyncTableGetMultiThreaded
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 09/Apr/20 17:56

I've already cut down the number of threads used by this test but it failed in nightly last night unable to close out its xml and locally it failed too in a run overnight. I ran it under harness and it seems well-behaved. It doesn't use much memory -- 700MB -- and thread counts are usual (~450).  It does use near 100% CPU which is a little unusual. Otherwise, looks fine.

Let me keep an eye on it. Could down the thread count more and use less processes... this makes it use less CPU. There does seems a bunch of overlap with tests done elsewhere.
Bug: Nightly CI's USE_YETUS_PRERELEASE feature is broken
Status: Open | Priority: Major | Resolution: 
Created: 16/Apr/20 22:29

I tried kicking off a [build|https://builds.apache.org/blue/organizations/jenkins/HBase%20Nightly/detail/master/1701/pipeline/] with the latest Yetus today, only to find

{noformat}
[2020-04-16T20:54:09.742Z] bash: /home/jenkins/jenkins-slave/workspace/HBase_Nightly_master/yetus-git/precommit/test-patch.sh: No such file or directory
{noformat}

Looks like we don't adjust the path to test-patch.sh based on working from a source tarball vs. a release tarball.
Bug: [RSGroup] Support renaming rsgroup
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 03/Apr/20 16:23

Rsgroup name once is decided at the beginning, it is difficult to rename it.

Current approach is removing all tables and servers back to default rsgroup, then delete it and add a rsgroup with the new name, after that moving regions and servers back. Or without moving back, if machine resources is ample. Anyway, it is an expensive operation:  moving regions, breaking region's locality.

And given that rsgroup is one kind of managements in cluster, and management sometimes changes, renaming is necessary.

It is simple in implementation. I'm working on it.
Bug: [Flakey Tests] TestHRegionWithInMemoryFlush#testWritesWhileScanning gets stuck MVCC
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 11/Apr/20 01:12

I see this in recent nightly fails on branch-2, my experimental branch. It happened in the two builds last night. It was only test to fail. Both failed with:

 2020-04-10 07:42:46,700 WARN  [Time-limited test] regionserver.MultiVersionConcurrencyControl(228): STUCK: MultiVersionConcurrencyControl{readPoint=8684,              writePoint=8686}

I ran the test in my  harness and it pushes up against heap limits for sure, especially after recent cut down in forked jvm size.

For now, see if alleviating scope of testWritesWhileScanning just when called from this test helps w/ flakeyness. Probably worth a deep dive why we get into this state w/ in-memory compaction.
Bug: Down forked JVM heap size from 2800m to 2200m for jdk8 and jdk11
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 07/Apr/20 18:34

Docker container we run tests in is hardcoded 20G. Our fork count is 0.25C currently. The jenkins machines are 16CPUs. 0.25C means 4CPUs so 4 forks running at any one time. Our current forked JVM heap size is 2800m if jdk8 or 3200m if jdk11. If we want to move our fork count to 0.5C, then that means 8 forks possibly running at once: i.e. 8 * 2800 = 22.4G... i.e. too big for the container.  This issue is about running w/ smaller forked jvm heap size. If 2200m then, its 19.6G which is cutting it close but might allow us sqeeze through (mvn takes 4G!). Lets see.
Bug: Align the internal.protobuf.version in hbase-protocol-shaded with hbase-thirdparty
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 11/Apr/20 02:42

The hbase-thirdparty-3.2.0 has already bumped the protobuf version to 3.11.4 but in hbase-protocol-shaded we still use 3.5.1-1.

It has already been done in HBASE-24119 for master branch, let's also do this on branch-2 and branch-2.3.
Bug: some tests of org.apache.hadoop.hbase.TestZooKeeper.* failed on aarch64
Status: Open | Priority: Major | Resolution: 
Created: 13/Apr/20 10:13

I build and test Hbase on aarch64, and  tests org.apache.hadoop.hbase.TestZooKeeper.testMasterZKSessionRecoveryFailure and testMasterSessionExpired failed by chance.  I found ARM CI in jenkins failed by chance too https://builds.apache.org/view/H-L/view/HBase/job/HBase-Nightly-ARM/73/testReport/junit/org.apache.hadoop.hbase/TestZooKeeper/testMasterZKSessionRecoveryFailure/, see:
{quote}Error Message
Unable to instantiate exception received from server:org.apache.hadoop.hbase.master.HMaster$MasterStoppedException.<init>(java.lang.String)
Stacktrace
org.apache.hadoop.hbase.DoNotRetryIOException: Unable to instantiate exception received from server:org.apache.hadoop.hbase.master.HMaster$MasterStoppedException.<init>(java.lang.String)
	at org.apache.hadoop.hbase.TestZooKeeper.testSanity(TestZooKeeper.java:153)
	at org.apache.hadoop.hbase.TestZooKeeper.testMasterZKSessionRecoveryFailure(TestZooKeeper.java:140)
Caused by: org.apache.hadoop.hbase.ipc.RemoteWithExtrasException: 
org.apache.hadoop.hbase.master.HMaster$MasterStoppedException
	at org.apache.hadoop.hbase.master.HMaster.checkInitialized(HMaster.java:2932)
	at org.apache.hadoop.hbase.master.HMaster.createTable(HMaster.java:2135)
	at org.apache.hadoop.hbase.master.MasterRpcServices.createTable(MasterRpcServices.java:716)
	at org.apache.hadoop.hbase.shaded.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java)
	at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:400)
	at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:133)
	at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:338)
	at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:318){quote}

It looks like the master is still stopped when we want to create table after stop it. I made thread to sleep 1 second in testSanity function before calling admin.createTable(desc), then I run the tests for more than 10 times and the tests are success:
**************************************************************************
{quote}private void testSanity(final String testName) throws Exception {
    String tableName = testName + "_" + System.currentTimeMillis();
    TableDescriptor desc = TableDescriptorBuilder.newBuilder(TableName.valueOf(tableName))
        .setColumnFamily(ColumnFamilyDescriptorBuilder.of("fam")).build();
    {color:#DE350B}Thread.sleep(1000);{color}
    LOG.info("Creating table " + tableName);
    Admin admin = TEST_UTIL.getAdmin();
    try {
      admin.createTable(desc);
    } finally {
      admin.close();
    }{quote}
**************************************************************************
Bug: Move CHANGES.txt to CHANGES.md. Add RELEASENOTES.md too on branch-2, branch-2.3, and master
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 10/Apr/20 00:14

Way back on HBASE-18828 for release 2.0.0 we moved to use releasemaker from yetus for generating changes/releasenotes. At that time we moved to *.md files instead of *.txt for CHANGES. Let me make the change on branch-2.3, branch-2 and master, the remaining outposts for *.txt files. Doing it because it confused a coworker (why wouldn't it?).
Bug: [Authorization] ServiceAuthorizationManager isn't dynamically updatable. And it should be.
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 06/Apr/20 08:42

Some more background information.

ServiceAuthorizationManager is responsible for the Services access rights defined in hbase-policy.xml which locates under $hbase_home/conf directory.

Currently, since it doesn't support update dynamically, we need to restart master/regionservers to make configurations take effect. It is an expensive and low efficient admin operation.

HDFS has the refreshPolicy to do that, HBase also has update_config command, we can make use of that.
Bug: Make ZK registry the default for branch-2 and branch-2.3
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 09/Apr/20 16:57
Affects Version/s: 2.3.0

This is already the case due to [this commit|https://github.com/apache/hbase/commit/558ee079fd04dfab8e61eca10ee98ab5bac89dfa], however it wasn't tagged with a jira ID.

I'm creating a new jira so that I can revert and re-apply this commit with this jira ID. Easier to track fix versions this way.
Bug: [Flakey Tests] Add adjunct Mob and Security ExportSnapshot unit tests that subclass TestExportSnapshotAdjunct
Status: Open | Priority: Major | Resolution: 
Created: 08/Apr/20 18:08

The parent issue moved a few tests out of the TestExportSnapshot suite so it would complete in less time. TES has a few subclassers that run the TES suite but with adornments (MOB, Security). With the parent move of a few methods to an adjunct, we should add adjuncts for the subclassers too. I was thinking the moved methods don't need MOB exercising. Security maybe. Probably best if we add the coverage. Suggested by our [~psomogyi]
Bug: [Flakey Tests] Add retry on thrift cmdline if client fails plus misc debug
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 06/Apr/20 22:37


{code}
    hbase-server/src/test/java/org/apache/hadoop/hbase/TestClusterPortAssignment.java
     Saw case where Master failed startup because of BindException but it came out wrapped
     in an IOE so we did not trip the BindException retry logic. Make the catch more general.

    hbase-server/src/test/java/org/apache/hadoop/hbase/TestInfoServers.java
     Add some debug and up timeouts. This test fails frequently for me
     locally.

    hbase-server/src/test/java/org/apache/hadoop/hbase/client/locking/TestEntityLocks.java
     Up the wait from 2x 200ms to 10x in case a pause on hardware or GC.
     This test fails locally and up on jenkins.

    hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestClearRegionBlockCache.java
     Debug. Have assert say what bad count was.

    hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestCompactingToCellFlatMapMemStore.java
     Fails on occasion. Found count is off by a few. Tricky to debug. Adding
     sub-issue to reenable.

    hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestRegionMergeTransactionOnCluster.java
     Debug. Add wait and check before moving to assert.

    hbase-thrift/src/test/java/org/apache/hadoop/hbase/thrift/TestThriftHttpServer.java
     Check for null before shutting; can be null if failed start.

    hbase-thrift/src/test/java/org/apache/hadoop/hbase/thrift/TestThriftServerCmdLine.java
     Add retry if client messes up connection. Fails for me locally.
{code}
Bug: [Flakey Tests] TestSnapshotScannerHDFSAclController#testRestoreSnapshot
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 01/Apr/20 04:19

Fails on occasion, 15% of the time according to flakie report. I can reproduce it failing locally. A single method fails. I don't follow how it is supposed to work (what looks wrong to me passes...). I noticed that if I ran testRestoreSnapshot on its own, it passed but failed when run as part of the test suite so I broke it out into its own suite. Now both old and new suites pass for me locally after 20 repeats. Let me push it up.
Bug: [Flakey Tests] TestSnapshotScannerHDFSAclController
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 02/Apr/20 07:54

According to HBASE-24097, TestSnapshotScannerHDFSAclController is still flakey:

https://builds.apache.org/job/HBase-Flaky-Tests/job/branch-2/5950/
Bug: [Flakey Test] TestThriftServerCmdLine.testRunThriftServer NPEs if InfoServer port clash
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 03/Apr/20 03:23

Push yesterday, HBASE-24100 [Flakey Tests] Add test to check we work properly when port clash setting up thriftserver, fixed the thrift protocol clash on ports. Today I ran into a clash where the info put up by thrift clashes. It looks like this. This issue adds tests where info port clashes.

{code}
 -------------------------------------------------------------------------------
 Test set: org.apache.hadoop.hbase.thrift.TestThriftServerCmdLine
 -------------------------------------------------------------------------------
 Tests run: 32, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 81.368 s <<< FAILURE! - in org.apache.hadoop.hbase.thrift.TestThriftServerCmdLine
 org.apache.hadoop.hbase.thrift.TestThriftServerCmdLine.testRunThriftServer[9]  Time elapsed: 10.161 s  <<< ERROR!
 java.lang.NullPointerException
   at org.apache.hadoop.hbase.thrift.TestThriftServerCmdLine.createBoundServer(TestThriftServerCmdLine.java:251)
   at org.apache.hadoop.hbase.thrift.TestThriftServerCmdLine.createBoundServer(TestThriftServerCmdLine.java:178)
   at org.apache.hadoop.hbase.thrift.TestThriftServerCmdLine.testRunThriftServer(TestThriftServerCmdLine.java:258)
{code}
Bug: Switch to `RawLocalFileSystem` as default FS for tests
Status: Open | Priority: Major | Resolution: 
Created: 06/Apr/20 21:01

In the PR discussion on HBASE-24106, [~elserj] [mentioned|https://github.com/apache/hbase/pull/1422#discussion_r403789851] that another project has had success with switching its unit test suite to use {{RawLocalFileSystem}} from {{LocalFileSystem}}. This is discussed in the context of the availability of the {{hsync}} and {{hflush}} stream capabilities, which are not available on {{LocalFileSystem}}.

Perhaps we should also consider doing the same for our default {{standalone}} user experience. I don't know if doing so should be a separate task from this one, or if completing one is effectively performing the implementation for the other.