giseldo/neodataset huggingface dataset:
[Bug] Moving a token to any 0 does not result in an update

# Summary

Moving a token to any 0 does not result in an update.

Moving a token so any of its coordinates are 0 will result in that coordinate not being updated.

## Steps to reproduce

1. Login
1. Enter tutorial
1. Drag a toke to the left most part of the map
1. Drag a toke to the top most part of the map
1. Drag a toke to the top-left part of the map

## What is the current *bug* behavior?

In each of these cases the coordinate that was suppose to be 0 is left with the original value.

## What is the expected *correct* behavior?

- [ ] Tokens should remain where they were dropped.

## Relevant logs and/or screenshots

```
moved {_character_version: 1, _id: "13", name: "Sarah", description: "Elven wizard", image: "/static/assets/sarah.png", …}backgroundColor: undefinedborderColor: ""borderMode: "coin"character: undefineddescription: "Elven wizard"image: "/static/assets/sarah.png"name: "Sarah"pos: {q: 3, r: 4}sceneId: "4"_character_version: 1_id: "13"_token_version: 1__proto__: Object
store.js?691c:70 Collection tokens:13 update: [{"op":"replace","path":"/pos/r","value":4},{"op":"replace","path":"/pos/q","value":3}]
store.js?bdbc:65 moved {_character_version: 1, _id: "13", name: "Sarah", description: "Elven wizard", image: "/static/assets/sarah.png", …}backgroundColor: undefinedborderColor: ""borderMode: "coin"character: undefineddescription: "Elven wizard"image: "/static/assets/sarah.png"name: "Sarah"pos: {q: 0, r: 1}sceneId: "4"_character_version: 1_id: "13"_token_version: 1__proto__: Object
store.js?691c:70 Collection tokens:13 update: [{"op":"replace","path":"/pos/r","value":1}]
```

- Note the beginning position `pos: {q: 3, r: 4}`
- Then the move order `pos: {q: 0, r: 1}`
- Both `q` and `r` are being changed
- The resulting operation only has the `r` `[{"op":"replace","path":"/pos/r","value":1}]`

## Cause (Fill out after fix)
<!-- This must be filled out before the Bug can be closed.  
This is used in our post mordems to understand where we can make improvements. -->

Chose one or more:
- [ ] Work was rushed
- [ ] Plan Incomplete
- [ ] Insufficient Tests
- [ ] Missed in Review

Story points: 1.0
[Bug] The Delete button does not remove characters anymore

# Summary

Deleting characters does not work.

## Steps to reproduce

1. Login
1. Enter tutorial
1. Select a token
1. Hit delete

## What is the current *bug* behavior?

- The Token remains.

## What is the expected *correct* behavior?

- [ ] The token should be removed.

## Relevant logs and/or screenshots

```
Uncaught (in promise) Error: Failed to invoke 'RemoveCharacter' due to an error on the server. HubException: Method does not exist.
    at _this.callbacks.<computed> (HubConnection.js?98b8:409)
    at HubConnection.processIncomingData (HubConnection.js?98b8:521)
    at WebSocketTransport.HubConnection.connection.onreceive (HubConnection.js?98b8:73)
    at WebSocket.webSocket.onmessage (WebSocketTransport.js?eb1a:112)
```

## Possible fixes

We recently introduced the idea of a token collection.  I think we need to make sure that it has a delete wired up.

## Cause (Fill out after fix)
<!-- This must be filled out before the Bug can be closed.  
This is used in our post mordems to understand where we can make improvements. -->

Chose one or more:
- [ ] Work was rushed
- [ ] Plan Incomplete
- [ ] Insufficient Tests
- [x] Missed in Review

Story points: 1.0
[Bug] Add Map tool non responsive

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "regression" or "bug" label:

- https://gitlab.com/mythicteam/mythictable/issues?label_name%5B%5D=Bug

and verify the issue you're about to submit isn't a duplicate.

Title suggestion: [Bug] Brief bug description
--->

# Summary
<!--Summarize the bug encountered concisely -->
When using the Add Map tool in Edge, nothing happens after selecting the file from the file explorer dialog.

## Steps to reproduce
Produced in Chrome and Firefox from the same account on the same campaign.
- Add a new scene
- Click "Add Map"
- Select a file larger than 1,024KB and click "Open" in the file explorer dialog
- Order something from amazon prime.
- Receive Amazon prime order next day.
- Verify that nothing has happened since selecting a file
- Clicking outside the dialog does not allow you to access the rest of the interface
- Hitting Escape does not allow you access the rest of the interface. 
- Can escape from Add Map dialog by uploading a file smaller than 1,024KB and selecting it.

## What is the current *bug* behavior?
Current behavior 
- forces user to upload maps smaller than 1,024KB without any notification of this limit
- forces a user to remain in the Add Map tool until uploading something smaller than the limit above
- provides no feedback to indicate that the operation of uploading has failed or is not allowed

## What is the expected *correct* behavior?
- provide notification of file size limit prior to uploading
- provide options for leaving the Add Map tool without having to upload an unwanted map
- provide feedback that an operation has failed or file is currently being uploaded

## Relevant logs and/or screenshots
<!--Paste any relevant logs - please use code blocks (```) to format console output,
logs, and code as it's tough to read otherwise. -->

## Possible fixes
<!-- If you can, link to the line of code that might be responsible for the problem -->
Possibly part of the default PHP upload file max limit. Unsure what method is being used for uploads but this is a common problem with default server configurations.

## Cause (Fill out after fix)
<!-- This must be filled out before the Bug can be closed.  
This is used in our post mordems to understand where we can make improvements. -->

Chose one or more:
- [ ] Work was rushed
- [ ] Plan Incomplete
- [ ] Insufficient Tests
- [ ] Missed in Review

Story points: 1.0
[Polish] Update Toolbar UX/UI

<!-- Title suggestion: [Polish] Name of improvement -->
<!-- Polish tasks track work to improve the look, feel and usability of existing features -->

# Description

Using mockups attached (TBD), update the in-game header to allow for ease of use. 

## Current State

The mixed state of the header (text, icons) makes for a confusing experience 

Pictures?

Attached

How to Fix it?

Implement new toolbar

## Unnecessary Logout Button

> Inside the board view, in the play UI, is a unecessary logout button right next to the annotation button, it's probably going to cause more frustration than give utility.


<!-- A note on weights
0 is trivial. Does not involve and code
1 is a button, documentation corrections, a quick fix
2 is a simple well known task
3 is for a somewhat simple task
5 is for a complicated story that requies a number of moving parts
8 is for a signifcant amount of work but should with perhaps some unkowns or external dependencies
Anything higher than 8 should be broken up into smaller more distinct stories.
-->

Story points: 3.0
[Improvement] Going in and out of campaigns causes unexpected state

# Description

Going in and our of campaigns without reloading the page causes a number of state changes that lead to unexpected results.

## The Problem

We've noticed that some things aren't being loaded (players) and some things are being loaded overtop of other state such as scenes.

## Background/Current State

This is caused by the fact that we're a single page application.  We need to make sure that state is dealt with properly or we load into a new page when loading the game.

## Solution

TBD

## Additional Information

## Steps

- [ ] TBD



<!-- A note on weights
0 is trivial. Does not involve and code
1 is a button, documentation corrections, a quick fix
2 is a simple well known task
3 is for a somewhat simple task
5 is for a complicated story that requies a number of moving parts
8 is for a signifcant amount of work but should with perhaps some unkowns or external dependencies
Anything higher than 8 should be broken up into smaller more distinct stories.
-->

Story points: 3.0
Automatically delete clones after N hours of inactivity

Goal
===
When a clone is inactive during N hours (should be configurable; default: 2), it has to be destroyed unless it is marked as "protected from deletion".

"Inactive" here means:

- no new connections,
- no SQL requests.

"during N hours" here means "at least N hours". It may be several minutes more. N is "global" for Database Lab instance.

TODO / How to implement
===
:question: implementation details are not defined, first we need design proposal and discussion.

On a separate note, do we need to tell the user somehow (in Database Lab API responses?) what is the current value of N?

Acceptance criteria
===
As a user, I know that if I don't use a clone, it will be deleted after N hours. I also know that if I mark it "protected" it will never get deleted.

Story points: 1.0
Bug: Endless wait if not enough privileges

Goal
===

TODO / How to implement
===
![Screenshot_2019-12-14_at_22.58.15](/uploads/fe961ceb6ff1e1c2dd8d8b27c6bae3f0/Screenshot_2019-12-14_at_22.58.15.png)
![Screenshot_2019-12-14_at_22.58.10](/uploads/9a5d5fb0bf27d59304e55066c375613a/Screenshot_2019-12-14_at_22.58.10.png)

Acceptance criteria
===

Story points: 1.0
Review all timestamps (db_state_at and others), clarify the meanings

Goal
===
`db_state_at` corresponds 

- [x] UI @dmius 
- [x] the platform reads the value from DB Lab API @dmius 
- [ ] at snapshotting time on DB Lab instance, we need to determine `db_state_at` and store it somewhere
    - [x] how do we get the timestamp if the originally we work with a replica? @NikolayS 
    - [ ] how do we get time timestamp if we deal with a master? @NikolayS 
    - [x] we do we store it? ---> in case of ZFS: zfs snapshot annotation, in other cases – depending on implementation (may be just files)
- [ ] dblab API to provide the data @anatolystansler 
- [ ] review texts

TODO / How to implement
===
Review all timestamps, clarify the meanings. The time of the latest available database state seems to be not correct (too fresh). UI expects db_state_at, if there is no such field, we show "unknown".

The logic for snapshots list exposure is needed. If a corresponding API call is made, we need to scan all existing snapshots, choose the proper ones according to some mask (should it be configurable?), and reply with list to the API call. Don't worry about long lists. Instead, consider providing a warning if the list exceeds 50 items ("The list of available snapshots exceeds 50, clean up some old ones not to waste of disk space and avoid potential performance degradation").

Acceptance criteria
===

Story points: 5.0
Declare Swagger and run it with DB lab instance

Goal
===
Provide a clear insight to DB Lab API with Swagger specification and run Swagger UI with DB Lab.

TODO / How to implement
===
- [x] Generate YAML file (API description for Swagger)
- [ ] Add Swagger to the project, decide on URL (may be `/`)
- [ ] (optional) Demo setup -- point to in in the docs (API reference)


Acceptance criteria
===
As a DB Lab API user I am able to quickly see API reference provided by Swagger and I can experiment with API in the browser.

Story points: 6.0
If Postgres fatal error is not “DB is not starting up”, then we notify user about such a fatal, with details

1) if cannot connect to 6xxx port ("connection refused" or so) – wait (but not more than 1min; after 1min give up and report an error),

2) FATAL "the database system is starting up" – this is normal. Wait. (Can take long in case of PITR)

3) any other FATALs -- give up immediately, report an error.

Story points: 2.0
DB Lab agent


- [x] Update README
- [x] Prepare Postila data for demo 
- [x] Move provision part of Joe to DB Lab as is
- [ ] First version of REST API (see number 3 API Commands).
- [ ] Joe works with REST API
- [ ] Divide DB Lab in 2 parts: agent and control (orchestration) instance
- [ ] Improve code (including AWS provision according to review done by Andrew)
- [ ] 443 port? SSL configuration (Let's Encrypt certificates)

1. Binary or container image
1. API -- token
1. API – commands:

    - clone create (timestamp)
    - clone reset (id)
    - clone list 
    - clone destroy (id)
    - status of DB Lab instance

Story points: 15.0
Refactoring after code review

Fix issues from code review:
- [x] Use dep 
or modules

- [x] Go modules https://gitlab.com/postgres-ai/database-lab/issues/34
- [x] Add comments to exported functions
- [x] Missed error processing https://goreportcard.com/report/gitlab.com/postgres-ai/joe#L278
- [x] golint and misspell warning from the same link (@NikolayS: I suppose there are multiple tools around – various linters – are we sure with our choice? let's discuss in this issue)
- [x] Use absolute path of package instead of dots in imports, e.g. "../ec2ctrl". Different in modules https://stackoverflow.com/a/53016796/319692
- [ ] Short write is possible here https://gitlab.com/postgres-ai/joe/blob/master/src/provision/aws.go#L323 better to do it like here https://golang.org/src/io/ioutil/ioutil.go?s=2534:2602#L69 or use lib functions (@Nikolays: this was written before moving the DB Lab code to a separate repository; so, the link is to `joe` repository. We need to start with applying changes in `database-lab` first because Joe code will eventually be based on it as well)

Story points: 4.0
Postgres connection by unix sockets for management

Goal
===

TODO / How to implement
===
Use unix sockets instead of TCP/IP to make Postgres connection. Better from security perspective and doesn't require port allocation. 

Switch to work via Unix socket (can be `trust`) for everything (management tasks) except the end-user connections. End user connections can (should?) be via TCP socket, but with the password required. (Currently `md5`, but we will need to support `ldap` as well, enterprise users need it 100%).

Acceptance criteria
===

Story points: 10.0
"logical": support restoring from a plain-text file

Goal
===
Currently, restore is working using pg_restore -- it means that plain-text format is not supported (when we need to use psql). We need to work with any format of dump, including plain-text

- auto-detect that we deal with plain-text format (might be compressed - is it possible to automatically handle popular compression formats too?)
- check if parallelization is not requested. If it is, print an error and exit (for plain-text files, we are going to support only single thread)
- use psql to load the file

TODO / How to implement
===
- Detect plain text format:
  - only work with plain text format
  - use `pg_restore -l dump.sql`
  - extract `dbname` - how to do it reliably :question: 
    - Parse database name from a dump file
    - Consider dumps made by `dumpall`
    - As a fallback (unless otherwise worked), we can use filename and convert (purify) it to a valid database name (manage the filename length and replace spaces, punctuation to underscore).
https://www.postgresql.org/docs/current/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS
- Validate configuration (parallel jobs)
- Build a psql restore command depends on format of a dump file:
  - partial restore is not supported
- Review and fix the docs:
  - keep in mind potential configuration changes
  - create a "how-to" guide to restore from plain-text files

Acceptance criteria
===
As a DLE admin, I can use any popular dump formats, including plain text files.

Story points: 16.0
Clean up a custom Docker network on DLE failure

Goal
===
DLE creates its own Docker network. On a retrieval error, the Docker network continues to exist.

If there are too many networks on the machine, an error occurs:
```
[ERROR] Error response from daemon: could not find an available, 
non-overlapping IPv4 address pool among the defaults to assign to the network
```

TODO / How to implement
===
On DLE retrieval failure:
- disconnect containers from a custom Docker network
- clean up custom Docker networks

Acceptance criteria
===

Story points: 2.0
DLE API/CLI– extend to support multiple volumes

Goal
===
DLE API/CLI need to support the case of "logical" (dump/restore) data provisioning when we have 2 or more volumes and some rotation logic:
- which snapshot belongs to which volume
- which clone belongs to clone volume
- what volume is active
- what are the characteristics of each volume (disk space used, etc)
- do we have spare volumes or all volumes are "busy" so we won't be able to perform next refresh unless we delete some clones (perhaps, this should be a warning of the global state of DLE)
- each volume is supposed to have a single snapshot – `dataStateAt` is also an attribute of a volume?

TODO / How to implement
===

TBD – @akartasov please add details here
- Add a new field `Pool string` to the `Snapshot` struct
- Clone contains a link to a snapshot that will contain a mention of the pool
- Add to the `GET /status` response an active pool
- Add to `GET /status` disk space metrics 
  - Return "N/A" if data cannot be provided, e.g. files-related details on LVM. 
  - Use both physical and logical sizes (`Used` and `LogicalReferenced`) for clones and snapshots.


Acceptance criteria
===
As an admin or user of DLE, I can see the info about all volumes available. Particularly, I can understand the details of data refresh policy and what to expect during the next refresh attempt.

Story points: 5.0
Provide config and diagnostic details in API

Goal
===
Be able to discover important (or all non-secret) configuration options and other valuable details.

TODO / How to implement
===
* [x] Uptime (time from control container start) - `/status`
* [x] Current file system (aka thin clone manager)  - `/status`
* [x] Compression ratio (in addition to disk size/usage) - `/status`
* [x] Clone size (in list)  - `/status`
* [x] Snapshot size (in list) - `/snapshots`
* [x] Total size of clones  - `/status`
* [x] Total size of snapshots  - `/status`
* [x] Docker image (used for clones, see the global config)  - `/status`

Return "N/A" if data cannot be provided, e.g. files-related details on LVM.

Use both physical and logical sizes (`Used` and `LogicalReferenced`) for clones and snapshots.

See also: https://gitlab.com/postgres-ai/platform/-/issues/156#data-thats-being-used

Example
```json
{
    "status": {
        "code": "OK",
        "message": "Instance is ready"
    },
    "fileSystem": {
        "mode": "zfs",
        "sizeHR": "192 MiB",
        "freeHR": "164 MiB",
        "usedHR": "28 MiB",
        "dataSizeHR": "121 MiB",
        "usedBySnapshotsHR": "183 KiB",
        "compressRatio": 4.53
    },
    "expectedCloningTime": 0,
    "numClones": 0,
    "clones": [],
    "pools": [
        {
            "name": "oldest5",
            "mode": "zfs",
            "dataStateAt": "",
            "status": "active",
            "cloneList": [],
            "disk": {
                "size": 201278976,
                "free": 171785728,
                "used": 29493248,
                "usedBySnapshots": 187392,
                "usedByChildren": 244224,
                "dataSize": 127020544,
                "compressRatio": 4.53
            }
        }
    ],
    "retrieving": {
        "mode": "",
        "status": "finished",
        "nextRefresh": "2021-08-26T12:15:00Z",
        "alerts": {
            "refresh_skipped": {
                "level": "warning",
                "message": "Pool to perform full refresh not found. Skip refreshing",
                "lastSeen": "2021-08-26T12:10:00.001036446Z",
                "count": 1
            }
        }
    },
    "provisioner": {
        "dockerImage": "postgresai/extended-postgres:11",
        "containerConfig": {
            "shm-size": "256MB"
        }
    },
    "startedAt": "2021-08-26T12:09:50Z"
}
```

Acceptance criteria
===

Story points: 6.0
Basic clone observability

Goal
===
To detect dangerous DDL and slow queries and describe reasons for it, DBLab should provide more data about DB migrations and EXPLAIN plans


TODO / How to implement
===
- [x] Add an additional mount point to store observation artifacts - 2h
- [x] Define artifacts structure and provide artifact management - (6-8h)
  ```
  /observer/
    clone_id/
        session_id/
            pg_stat_statements/
                statements.csv
            pg_stats/
                pg_stats_database.csv
                pg_stat_bgwriter.csv
                pg_stat_user_tables.csv
                objects_size.csv
            summary.json
   ```
   
   **summary.json**
   ```
    {
      "session_id": 1,
      "clone_id": "c0nta38hmvj68nrgn7jg",
      "duration": {
        "total": "35s",
        "started_at": "2021-02-19T15:11:23.508Z",
        "finished_at": "2021-02-19T15:11:59.106167994Z",
        "max_query": "239ms"
      },
      "db_size": {
        "total": "7.7 MiB",
        "diff": "10 B",
        "objects_stat": {
          "count": 62,
          "row_estimate_sum": 23232,
          "total_size_bytes_sum": 8101888,
          "table_size_bytes_sum": 4218880,
          "indexes_size_bytes_sum": 3244032,
          "toast_size_bytes_sum": 638976
        }
      },
      "locks": {
        "total_interval": 4,
        "warning_interval": 0
      },
      "stats": {}
    }
   ```
- [x] Collect data during observation sessions and store observation results as files - (14-18h)
  - dangerous locks detected (consider as an artifact)
  - duration
    - duration in Lab
    - estimated duration for prod
  - pg_stat_statements - as an “amount of work” - buffers read/hit/dirtied/written
  - pg_stat_*** standard views:
    - op/tuple stats
    - pg_stat_bgwriter (checkpointer, bgwriter, backend buffer stats)
    - WAL written
  - DB and its objects sizes and changes (similarly to L001 in postgres-checkup)
  - dead tuples and bloat: should we analyze them?
    - autovacuum settings – so far we didn't take care of them! (match prod)
  - summary: ???? (what should be there - discuss and decide)
- [x] Serve results via DLE API - (8-10h)
  - GET `/observation/results/{clone_id}/{session_id}` - returns a session summary
  - GET `/observation/results/{clone_id}/{session_id}/list` - returns a list of session result files
  - GET `/observation/results/{clone_id}/{session_id}/file?path=pg_stat_activity/activity.csv` - download a session result file
- [x] Clean up artifacts when destroying a clone - 2h


Acceptance criteria
===

Story points: 36.0
Add an ability not to reset passwords of existing users in clones

When a clone creates, an additional superuser is added and all passwords for current users are reset.

There are some cases when the DB instance has several dozen users with different privileges which are significant. In such conditions, it is not possible to test the difference in privileges. 

So, we need an additional setting to avoid resetting the existing user passwords:

``` yaml
   provision: 
     keepUserPasswords: true
```

Story points: 3.0
Automatically start PostgreSQL in a sync instance  + "merge" two Postgres images into one

Goal
===
To have an ability restart sync container manually

TODO / How to implement
===
- prepare extended sync instance: add wal-g
- adjust PostgreSQL configuration before start container
- tune health checks, make sure it works
- use one container to run them all
- get rid of sync instance image

Acceptance criteria
===

Story points: 8.0
Build latest images for minor commit tags

Goal
===
To have the latest image of minor versions including bugfixes

TODO / How to implement
===
Build latest images for minor commit tags.
Example: tag `2.0.1` additionally produces
- `dblab:2.0-latest`
- `dblab-server:2.0-latest`
- `dblab-swagger-ui:2.0-latest`

Acceptance criteria
===

Story points: 2.0