- Removed `readCollectionQuotaInfo` call. The only data we need is the usage size which we can get via the ARM metrics call instead.
- Added `getCollectionUsageSize` which fetches the `DataUsage` and `IndexUsage` metrics, converts them to KB, and returns the sum as the total usage size
- Make sure we pass the error message string instead of an error object when we call `TelemetryProcessor.traceFailure` since TelemetryProcessor will call `JSON.stringify` on the error object which would result in an empty object
- Removed ErrorParserUtility since it only works on specific error types. We can just log the full error message and manually derive information we need from the message.
- Added option to include stack trace in `getErrorMessage`. This is useful for figuring out where the client side script errors are coming from.
- Some minor refactors
- created `getErrorMessage` function which takes in an error string or any type of error object and returns the correct error message
- replaced `error.message` with `getErrorMessage` since `error` could be a string in some cases
- merged sendNotificationForError.ts with ErrorHandlingUtils.ts
- some minor refactoring
In part 2, I will make the following changes:
- Make `Logger.logError` function take an error message string instead of an error object. This will reduce some redundancy where the `getErrorMessage` function is being called twice (the error object passed by the caller is already an error message).
- Update every `TelemetryProcessor.traceFailure` call to make sure we pass in an error message instead of an error object since we stringify the data we send.
- removed the `isFixed` check in both new and old settings tab so that the options to switch between manual and autoscale shows up for fixed collections
- updated the message below the text box to inform the users that the max RU for fixed collections is 10000
- updated validation rule so that the max RU cannot exceed 10000 for fixed collections for both autoscale and manual
1. After moving read databases call to RP for Tables API, we lose the `_rid` property. Since we are reading Table's database offer with SDK, we need the `_rid` of the database to find its offer. Without `_rid`, we won't be able to find the database offer and the Scale tab would disappear again. The fix is to use SDK to read databases for Table API so we have `_rid`.
2. There's a bug in the non-aad code path for updating offers which prevents users from switching from manual to autoscale and vice versa. The fix is to properly set the option headers.
Since I've cleaned up all the places that use `_rid` and `_self` of a database in my previous commit (https://github.com/Azure/cosmos-explorer/commit/d525afa14272ea3c7c90df2c20949aba2f145daa), we are safe to use RP to read databases for all APIs except Tables.
For Tables API, since RP doesn't support any database level operations, I have to hardcode the read database response. The only property we need in the Tables database is the id which is the string that we display in the resource tree.
Currently we maintain a cache of all database offers which can be stale since we have moved to lazy loading the offers. Instead of reading the offer from the cache, we should just find the selected database and get the offer directly by calling `database.offer()`.
* Create GenericPaneComponent and use it to migrate UploadItemsPane to React
* Add helper functions for building each panel section
* Address comments and some styling changes
* Unsubscribe to isNotificationConsoleExpanded when component unmounts
victor-meng
