av9ash/GitBugs huggingface dataset:
Bug: DBB released too early and dirty data for some operations
Status: Resolved | Priority: Critical | Resolution: Fixed
Created: 29/Jun/21 08:31
Affects Version/s: 2.0.0

Before HBASE-25187, we found there are regionserver JVM crashing problems on our production clusters, the coredump infos are as follows,
{code:java}
Stack: [0x00007f621ba8d000,0x00007f621bb8e000],  sp=0x00007f621bb8c0e0,  free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
J 10829 C2 org.apache.hadoop.hbase.ByteBufferKeyValue.getTimestamp()J (9 bytes) @ 0x00007f6a5ee11b2d [0x00007f6a5ee11ae0+0x4d]
J 22844 C2 org.apache.hadoop.hbase.regionserver.HRegion.doCheckAndRowMutate([B[B[BLorg/apache/hadoop/hbase/filter/CompareFilter$CompareOp;Lorg/apache/hadoop/hbase/filter/ByteArrayComparable;Lorg/apache/hadoop/hbase/client/RowMutations;Lorg/apache/hadoop/hbase/client/Mutation;Z)Z (540 bytes) @ 0x00007f6a60bed144 [0x00007f6a60beb320+0x1e24]
J 17972 C2 org.apache.hadoop.hbase.regionserver.RSRpcServices.checkAndRowMutate(Lorg/apache/hadoop/hbase/regionserver/Region;Ljava/util/List;Lorg/apache/hadoop/hbase/CellScanner;[B[B[BLorg/apache/hadoop/hbase/filter/CompareFilter$CompareOp;Lorg/apache/hadoop/hbase/filter/ByteArrayComparable;Lorg/apache/hadoop/hbase/shaded/protobuf/generated/ClientProtos$RegionActionResult$Builder;)Z (312 bytes) @ 0x00007f6a5f4a7ed0 [0x00007f6a5f4a6f40+0xf90]
J 26197 C2 org.apache.hadoop.hbase.regionserver.RSRpcServices.multi(Lorg/apache/hbase/thirdparty/com/google/protobuf/RpcController;Lorg/apache/hadoop/hbase/shaded/protobuf/generated/ClientProtos$MultiRequest;)Lorg/apache/hadoop/hbase/shaded/protobuf/generated/ClientProtos$MultiResponse; (644 bytes) @ 0x00007f6a61538b0c [0x00007f6a61537940+0x11cc]
J 26332 C2 org.apache.hadoop.hbase.ipc.RpcServer.call(Lorg/apache/hadoop/hbase/ipc/RpcCall;Lorg/apache/hadoop/hbase/monitoring/MonitoredRPCHandler;)Lorg/apache/hadoop/hbase/util/Pair; (566 bytes) @ 0x00007f6a615e8228 [0x00007f6a615e79c0+0x868]
J 20563 C2 org.apache.hadoop.hbase.ipc.CallRunner.run()V (1196 bytes) @ 0x00007f6a60711a4c [0x00007f6a60711000+0xa4c]
J 19656% C2 org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(Ljava/util/concurrent/BlockingQueue;Ljava/util/concurrent/atomic/AtomicInteger;)V (338 bytes) @ 0x00007f6a6039a414 [0x00007f6a6039a320+0xf4]
j  org.apache.hadoop.hbase.ipc.RpcExecutor$1.run()V+24
j  java.lang.Thread.run()V+11
v  ~StubRoutines::call_stub
{code}
I have made a UT to reproduce this error, it can occur 100%。

After HBASE-25187，the check result of the checkAndMutate will be false, because it read wrong/dirty data from the released ByteBuff.
Bug: MOB data loss - incorrect concatenation of MOB_FILE_REFS 
Status: Resolved | Priority: Critical | Resolution: Fixed
Created: 04/Jun/21 14:09
Affects Version/s: 3.0.0-alpha-1

Active MOB files can be deleted by MobFileCleanerChore. The MOB_FILE_REFS are wrongly concatenated when multiple files or tables are stored. During the MOB cleanup HBase wants to keep the incorrectly concatenated file and considers the real file as deletable.

{noformat}
2021-06-03 15:03:09,876 TRACE org.apache.hadoop.hbase.mob.MobFileCleanerChore: Specific mob references found for store=hdfs://c1377-node2.coelab.cloudera.com:8020/hbase/data/default/IntegrationTestIngestWithMOB/1df6561244ecc434f505501e6bda9af0/test_cf/2956445a41184488b914e93199df905a : {IntegrationTestIngestWithMOB=[d41d8cd98f00b204e9800998ecf8427e20210603a6c8c0e5bf8548649b0009b156452c21_1df6561244ecc434f505501e6bda9af0d41d8cd98f00b204e9800998ecf8427e20210603497714eabbe5418c9d52382a4808e986_1df6561244ecc434f505501e6bda9af0, d41d8cd98f00b204e9800998ecf8427e202106037464cbddc86943a1bad77d52a3bd412c_1df6561244ecc434f505501e6bda9af0]} 
...
2021-06-03 15:03:10,208 TRACE org.apache.hadoop.hbase.mob.MobFileCleanerChore: Archiving MOB file hdfs://c1377-node2.coelab.cloudera.com:8020/hbase/mobdir/data/default/IntegrationTestIngestWithMOB/e9b5d936e7f55a4f1c3246a8d5ce53c2/test_cf/d41d8cd98f00b204e9800998ecf8427e20210603497714eabbe5418c9d52382a4808e986_1df6561244ecc434f505501e6bda9af0 creation time=1622729860319
2021-06-03 15:03:10,467 DEBUG org.apache.hadoop.hbase.mob.MobFileCleanerChore: MOB Cleaner is archiving: hdfs://c1377-node2.coelab.cloudera.com:8020/hbase/mobdir/data/default/IntegrationTestIngestWithMOB/e9b5d936e7f55a4f1c3246a8d5ce53c2/test_cf/d41d8cd98f00b204e9800998ecf8427e20210603497714eabbe5418c9d52382a4808e986_1df6561244ecc434f505501e6bda9af0
{noformat}
Bug: It is not reliable to use nodeDeleted event to track region server's death
Status: Resolved | Priority: Critical | Resolution: Fixed
Created: 23/Jun/21 15:40

When implementing HBASE-26011, [~sunxin] pointed out an interesting scenario, where a region server up and down between two sync requests, then we can not know the death of the region server.

https://github.com/apache/hbase/pull/3405#discussion_r656720923

This is a valid point, and when thinking of a solution, I noticed that, the current zk iplementation has the same problem. Notice that, a watcher on zk can only be triggered once, so after zk triggers the watcher, and before you set a new watcher, it is possible that a region server is up and down, and you will miss the nodeDeleted event for this region server.

I think, the general approach here, which could works for both master based and zk based replication tracker is that, we should not rely on the tracker to tell you which region server is dead. Instead, we just provide the list of live regionservers, and the upper layer should compare this list with the expected list(for replication, the list should be gotten by listing replicators), to detect the dead region servers.
Bug: FSHLog WAL lockup with sync future reuse [RS deadlock]
Status: Resolved | Priority: Critical | Resolution: Fixed
Created: 08/Jun/21 21:08
Affects Version/s: 1.7.0

We use FSHLog as the WAL implementation (branch-1 based) and under heavy load we noticed the WAL system gets locked up due to a subtle bug involving racy code with sync future reuse. This bug applies to all FSHLog implementations across branches.

Symptoms:

On heavily loaded clusters with large write load we noticed that the region servers are hanging abruptly with filled up handler queues and stuck MVCC indicating appends/syncs not making any progress.

{noformat}
 WARN  [8,queue=9,port=60020] regionserver.MultiVersionConcurrencyControl - STUCK for : 296000 millis. MultiVersionConcurrencyControl{readPoint=172383686, writePoint=172383690, regionName=1ce4003ab60120057734ffe367667dca}
 WARN  [6,queue=2,port=60020] regionserver.MultiVersionConcurrencyControl - STUCK for : 296000 millis. MultiVersionConcurrencyControl{readPoint=171504376, writePoint=171504381, regionName=7c441d7243f9f504194dae6bf2622631}
{noformat}

All the handlers are stuck waiting for the sync futures and timing out.

{noformat}
 java.lang.Object.wait(Native Method)
    org.apache.hadoop.hbase.regionserver.wal.SyncFuture.get(SyncFuture.java:183)
    org.apache.hadoop.hbase.regionserver.wal.FSHLog.blockOnSync(FSHLog.java:1509)
    .....
{noformat}

Log rolling is stuck because it was unable to attain a safe point

{noformat}
   java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277) 
org.apache.hadoop.hbase.regionserver.wal.FSHLog$SafePointZigZagLatch.waitSafePoint(FSHLog.java:1799)
 org.apache.hadoop.hbase.regionserver.wal.FSHLog.replaceWriter(FSHLog.java:900)
{noformat}

and the Ring buffer consumer thinks that there are some outstanding syncs that need to finish..

{noformat}
  org.apache.hadoop.hbase.regionserver.wal.FSHLog$RingBufferEventHandler.attainSafePoint(FSHLog.java:2031)
    org.apache.hadoop.hbase.regionserver.wal.FSHLog$RingBufferEventHandler.onEvent(FSHLog.java:1999)
    org.apache.hadoop.hbase.regionserver.wal.FSHLog$RingBufferEventHandler.onEvent(FSHLog.java:1857)
{noformat}

On the other hand, SyncRunner threads are idle and just waiting for work implying that there are no pending SyncFutures that need to be run

{noformat}
   sun.misc.Unsafe.park(Native Method)
    java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
    java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
    java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
    org.apache.hadoop.hbase.regionserver.wal.FSHLog$SyncRunner.run(FSHLog.java:1297)
    java.lang.Thread.run(Thread.java:748)
{noformat}

Overall the WAL system is dead locked and could make no progress until it was aborted. I got to the bottom of this issue and have a patch that can fix it (more details in the comments due to word limit in the description).
Bug: Add missing CFs in meta during HBase 1 to 2.3+ Upgrade
Status: Resolved | Priority: Critical | Resolution: Fixed
Created: 20/May/21 16:28
Affects Version/s: 2.3.0

Making note of this issue in case others run into it. At my place of employ, we tried to upgrade a cluster that was an hbase-1.2.x version to an hbase-2.3.5 but it failed because meta didn't have the 'table' column family.

Up to 2.3.0, hbase:meta was hardcoded. HBASE-12035 added the 'table' CF for hbase-2.0.0. HBASE-23782 (2.3.0) undid hardcoding of the hbase:meta schema; i.e. reading hbase:meta schema from the filesystem. The hbase:meta schema is only created on initial install. If an upgrade over existing data, the hbase-1 hbase:meta will not be suitable for hbase-2.3.x context as it will be missing columnfamilies needed to run (HBASE-23055 made it so hbase:meta could be altered (2.3.0) but probably of no use since Master won't come up).

It would be a nice-to-have if a user could go from hbase1 to hbase.2.3.0 w/o having to first install an hbase2 that is earlier than 2.3.0 but needs to be demand before we would work on it; meantime, install an intermediate hbase2 version before going to hbase-2.3.0+ if coming from hbase-1.x
Bug: ServerManager.getOnlineServer may miss some region servers when refreshing state in some procedure implementations
Status: Resolved | Priority: Critical | Resolution: Fixed
Created: 14/Apr/21 16:54

[https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3025/9/testReport/org.apache.hadoop.hbase.replication/TestSyncReplicationStandbyKillRS/precommit_checks___yetus_jdk8_Hadoop3_checks______/]
{code:java}
...[truncated 391170 chars]...
76d634:45149.replicationSource,1] regionserver.HRegionServer(2351): STOPPED: Unexpected exception in RS:2;ece3af76d634:45149.replicationSource,1
2021-04-11T11:14:40,268 INFO  [RS:2;ece3af76d634:45149] regionserver.HeapMemoryManager(218): Stopping
2021-04-11T11:14:40,268 INFO  [MemStoreFlusher.0] regionserver.MemStoreFlusher$FlushHandler(384): MemStoreFlusher.0 exiting
2021-04-11T11:14:40,268 INFO  [RS:2;ece3af76d634:45149] flush.RegionServerFlushTableProcedureManager(118): Stopping region server flush procedure manager abruptly.
2021-04-11T11:14:40,270 INFO  [RS:2;ece3af76d634:45149] snapshot.RegionServerSnapshotManager(136): Stopping RegionServerSnapshotManager abruptly.
2021-04-11T11:14:40,270 INFO  [RS:2;ece3af76d634:45149] regionserver.HRegionServer(1146): aborting server ece3af76d634,45149,1618139661734
2021-04-11T11:14:40,272 ERROR [ReplicationExecutor-0.replicationSource,1-ece3af76d634,44745,1618139625245] regionserver.ReplicationSource(428): Unexpected exception in ReplicationExecutor-0.replicationSource,1-ece3af76d634,44745,1618139625245 currentPath=null
java.lang.IllegalStateException: Source should be active.
	at org.apache.hadoop.hbase.replication.regionserver.ReplicationSource.initialize(ReplicationSource.java:547) ~[classes/:?]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_282]
2021-04-11T11:14:40,272 DEBUG [ReplicationExecutor-0.replicationSource,1-ece3af76d634,44745,1618139625245] regionserver.HRegionServer(2576): Abort already in progress. Ignoring the current request with reason: Unexpected exception in ReplicationExecutor-0.replicationSource,1-ece3af76d634,44745,1618139625245
{code}
Maybe it should use HBASE-24877 to avoid failure of the initialize of ReplicationSource.
Bug: Exclude tomcat-embed-core from libthrift
Status: Resolved | Priority: Critical | Resolution: Fixed
Created: 09/Apr/21 17:35
Affects Version/s: 2.2.7

HBASE-25568 upgraded the Thrift dependency to 0.14.1 to fix a known CVE but a dependency issue in libthrift brings in tomcat-embed-core which has many vulnerabilities. See: THRIFT-5375
Since this dependency is used in Thrift only for a test we can safely exclude it inside HBase.
Bug: Bulk Import fails with java.io.IOException: Type mismatch in value from map
Status: In Progress | Priority: Major | Resolution: 
Created: 03/May/21 15:59
Affects Version/s: 2.2.5

Bulk Import with {{-Dimport.bulk.output=/HFILES -Dimport.bulk.hasLargeResult=true}} always results in
{noformat}
Error: java.io.IOException: Type mismatch in value from map: expected org.apache.hadoop.hbase.util.MapReduceExtendedCell, received org.apache.hadoop.hbase.IndividualBytesFieldCell
        at org.apache.hadoop.mapred.MapTask$MapOutputBuffer.collect(MapTask.java:1077)
        at org.apache.hadoop.mapred.MapTask$NewOutputCollector.write(MapTask.java:715)
        at org.apache.hadoop.mapreduce.task.TaskInputOutputContextImpl.write(TaskInputOutputContextImpl.java:89)
        at org.apache.hadoop.mapreduce.lib.map.WrappedMapper$Context.write(WrappedMapper.java:112)
        at org.apache.hadoop.hbase.mapreduce.Import$CellSortImporter.map(Import.java:423)
        at org.apache.hadoop.hbase.mapreduce.Import$CellSortImporter.map(Import.java:394)
        at org.apache.hadoop.mapreduce.Mapper.run(Mapper.java:146)
        at org.apache.hadoop.mapred.MapTask.runNewMapper(MapTask.java:787)
        at org.apache.hadoop.mapred.MapTask.run(MapTask.java:341)
        at org.apache.hadoop.mapred.YarnChild$2.run(YarnChild.java:175)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.Subject.doAs(Subject.java:422)
        at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1844)
        at org.apache.hadoop.mapred.YarnChild.main(YarnChild.java:169)
{noformat}
The Problem is that in {{org.apache.hadoop.hbase.mapreduce.Import.CellSortImporter#map}} the {{Cell}} coming from {{value.rawCells()}} (which is of type {{org.apache.hadoop.hbase.IndividualBytesFieldCell}}) is directly written to the context without wrapping it into {{MapReduceExtendedCell}} (like it happens at {{CellImporter#map}}).

IMHO [line 423|https://github.com/apache/hbase/blob/f76a601273e834267b55c0cda12474590283fd4c/hbase-mapreduce/src/main/java/org/apache/hadoop/hbase/mapreduce/Import.java#L423] must look like this:
{code:java}
    context.write(new CellWritableComparable(ret), new MapReduceExtendedCell(ret));
{code}
 Furthermore it seems to me that this is also wrong in all subsequent versions
Bug: TestRSGroupsWithACL.setupBeforeClass is flaky
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 11/Apr/21 06:54

[ERROR] Failures: [ERROR] TestRSGroupsWithACL.setupBeforeClass:136->SecureTestUtil.grantGlobal:345->SecureTestUtil.updateACLs:313 Waiting timed out after [10,000] msec

*[https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3025/8/artifact/yetus-jdk8-hadoop3-check/output/patch-unit-hbase-server.txt]*
Bug: tableSkewCostFunction aggregate cost per table incorrectly
Status: Resolved | Priority: Major | Resolution: Duplicate
Created: 22/Jun/21 18:16

There is another bug in the original tableSkew cost function for aggregation of the cost per table:

If we have 10 regions, one per table, evenly distributed on 10 nodes, the cost is scale to 1.0.

The more tables we have, the closer the value will be to 1.0. The cost function becomes useless.

All the balancer tests were set up with large numbers of tables with minimal regions per table. This artificially inflates the total cost and trigger balancer runs. With this fix on TableSkewFunction, we need to overhaul the tests too. We also need to add tests that reflect more diversified scenarios for table distribution such as large tables with large numbers of regions.
{code:java}
protected double cost() {
 double max = cluster.numRegions;
 double min = ((double) cluster.numRegions) / cluster.numServers;
 double value = 0;

 for (int i = 0; i < cluster.numMaxRegionsPerTable.length; i++) {
 value += cluster.numMaxRegionsPerTable[i];
 }
 LOG.info("min = {}, max = {}, cost= {}", min, max, value);
 return scale(min, max, value);
 }
}{code}
Bug: TableSkewCostFunction need to use aggregated deviation
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 06/Apr/21 20:58

TableSkewCostFunction uses the sum of the max deviation region per server for all tables as the measure of unevenness. It doesn't work in a very common scenario in operations. Say we have 100 regions on 50 nodes, two on each. We add 50 new nodes and they have 0 each. The max deviation from the mean is 1, compared to 99 in the worst case scenario of 100 regions on a single server. The normalized cost is 1/99 = 0.011 < default threshold of 0.05. Balancer wouldn't move.  The proposal is to use aggregated deviation of the count per region server to detect this scenario, generating a cost of 100/198 = 0.5 in this case.
Bug: Dual File Compaction
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 04/Jun/21 23:46

HBase stores tables row by row in its files, HFiles. An HFile is composed of blocks. The number of rows stored in a block depends on the row sizes. The number of rows per block gets lower when rows get larger on disk due to multiple row versions since HBase stores all row versions sequentially in the same HFile after compaction. However, applications (e.g., Phoenix) mostly query the most recent row versions.

The default compactor in HBase compacts HFiles into one file. This Jira introduces a new store file writer which writes the retained cells by compaction into two files, which will be called DualFileWriter. One of these files will include the live cells. This file will be called a live-version file. The other file will include the rest of the cells, that is, historical versions. This file will be called a historical-version file. DualFileWriter will work with the default compactor.

The historical files will not be read for the scans scanning latest row versions. This eliminates scanning unnecessary cell versions in compacted files and thus it is expected to improve performance of these scans.
Bug: Support an overall coarse and fast balance strategy for StochasticLoadBalancer
Status: Open | Priority: Major | Resolution: 
Created: 12/Apr/21 06:58
Affects Version/s: 1.4.13

When we use StochasticLoadBalancer + balanceByTable, we could face two difficulties.
 # For each table, their regions are distributed uniformly, but for the overall cluster, still exiting imbalance between RSes;
 # When there are large-scaled restart of RSes, or expansion for groups or cluster, we hope the balancer can execute as soon as possible, but the StochasticLoadBalancer may need a lot of time to compute costs.

We can detect these circumstances in StochasticLoadBalancer(such as using the percentage of skew tables), and before the normal balance steps trying, we can add a strategy to let it just balance like the SimpleLoadBalancer or use few light cost functions here.
Bug: Support JDK17
Status: Open | Priority: Major | Resolution: 
Created: 29/Jun/21 10:02

JDK 17 is the next Java LTS, coming out this September.

It brings a number of goodies. One of which is the production-ready ZGC (available since JDK15). (as well as the Shenandoah GC, available since JDK15)

After September 2021, there will be three Java LTS versions: Java 8, Java 11 and Java 17. Java 8 will still be the mainstream SDK in the foreseeable future, so I am not looking to take advantage of the new APIs that are only available in JDK17. This jira aims to support HBase on all three JDK LTS.

Porting HBase to JDK17 is not a big hurdle. HBase (master branch) builds successfully on JDK17. A few tests fail mostly due to the new (more strict) Java module isolation enforcement. I have a small PoC that I will post here in the coming days.

What I am trying to achieve is to add an experimental support for JDK17. It will be interesting to benchmark HBase on ZGC and Shenandoah and determine if we should set our default GC to them. By then, we'll be able to claim production-ready support.
Bug: [JDK17] Replace the usage of deprecated API ThreadGroup.destroy()
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 30/Jun/21 06:34

According to the JDK17 doc, ThreadGroup.destroy() is deprecated because
{quote}Deprecated, for removal: This API element is subject to removal in a future version.
{quote}
The API and mechanism for destroying a ThreadGroup is inherently flawed. The ability to explicitly or automatically destroy a thread group will be removed in a future release.

[https://download.java.net/java/early_access/jdk17/docs/api/java.base/java/lang/ThreadGroup.html#destroy(])

We don't necessarily need to remove this usage now, but the warning sounds bad enough.
Bug: [JDK17] Track JDK17 unit test failures
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 30/Jun/21 06:19

As of now, there are still two failed unit tests after exporting JDK internal modules and the modifier access hack.

{noformat}

[ERROR] Tests run: 7, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.217 s <<< FAILURE! - in org.apache.hadoop.hbase.io.TestHeapSize
[ERROR] org.apache.hadoop.hbase.io.TestHeapSize.testSizes  Time elapsed: 0.041 s  <<< FAILURE!
java.lang.AssertionError: expected:<160> but was:<152>
        at org.apache.hadoop.hbase.io.TestHeapSize.testSizes(TestHeapSize.java:335)

[ERROR] org.apache.hadoop.hbase.io.TestHeapSize.testNativeSizes  Time elapsed: 0.01 s  <<< FAILURE!
java.lang.AssertionError: expected:<72> but was:<64>
        at org.apache.hadoop.hbase.io.TestHeapSize.testNativeSizes(TestHeapSize.java:134)

[INFO] Running org.apache.hadoop.hbase.io.Tes


[ERROR] Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.697 s <<< FAILURE! - in org.apache.hadoop.hbase.ipc.TestBufferChain
[ERROR] org.apache.hadoop.hbase.ipc.TestBufferChain.testWithSpy  Time elapsed: 0.537 s  <<< ERROR!
java.lang.NullPointerException: Cannot enter synchronized block because "this.closeLock" is null
        at org.apache.hadoop.hbase.ipc.TestBufferChain.testWithSpy(TestBufferChain.java:119)


{noformat}

It appears that JDK17 makes the heap size estimate different than before. Not sure why.

TestBufferChain.testWithSpy  failure might be because of yet another unexported module.
Bug: Add support to take parallel backups
Status: In Progress | Priority: Major | Resolution: 
Created: 27/Jun/21 14:22
Affects Version/s: 3.0.0-alpha-2

*Existing Design:*

!existing_design.png|width=632,height=1238!

*Proposed Changes:*

*!proposed_design.png|width=637,height=1300!*