[$500] IOU - Description entered as "0" disappears after selecting a category while making money request

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 1.3.89-2
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
Action Performed:

Go to https://staging.new.expensify.com/
Tap fab
Tap request money---manual
Enter an amount
5.Tap next
Select a Workspace
Tap Request amount
Tao on IOU to open IOU detail page
Tap on description and enter zero "0" and save
Tap on category and select any category
Scroll up to see the description section

Expected Result:
Description entered as zero "0" must not disappear after selecting a category while making money request with a workspace
Actual Result:
Description entered as zero "0" disappears after selecting a category while making money request with a workspace
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos

Android: Native

Android: mWeb Chrome

https://github.com/Expensify/App/assets/78819774/bb2a57c8-01a8-4879-86dd-03825bb94ee0

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~011a3dd7030d48e5a3
Upwork Job ID:<PHONE_NUMBER>525471744
Last Price Increase: 2023-10-23

When entered only number in description backend is sending description in number format, this is additionally causing app to crash when opening description
I think this should be fixed in backend where description type always should be a string

https://github.com/Expensify/App/assets/59907218/283c14af-2f2a-4376-a2a3-ccff3685c79d

Proposal
Please re-state the problem that we are trying to solve in this issue.
When we enter 0 as a description for an IOU, it does not reflect the value we entered when the IOU is viewed.
What is the root cause of that problem?
Even though we save the 0 as a string type, when it is getting loaded it comes back as a number and the getDescription function in TransactionUtils.ts is returning a '' instead of the number.
What changes do you think we should make in order to solve the problem?
In TransactionUtils.ts, update the getDescription() function to convert the comment to a string.
function getDescription(transaction: Transaction): string {
    return transaction?.comment?.comment?.toString() ?? '';
}

What alternative solutions did you explore? (Optional)

@alitoshmatov While it would be ideal for the backend to return numeric values as strings, I think we can move forward with a proposal here since it's fixable in the app.

Both proposals by @yh-0218 and @iiredalert correctly identify the root cause, and their corresponding solutions work as expected. However, since this is a simple, straightforward fix and the proposal by @yh-0218 was posted first, I recommend we go with @yh-0218's proposal.
@yh-0218  It's a cleaner approach to place the toString() method in the TransactionUtils.getDescription method implementation. Also, in the future, please flesh out your proposals more. In your proposal for this issue, the root cause can be described in more detail.
🎀 👀 🎀 C+ reviewed.

This has a way older duplicate – https://github.com/Expensify/App/issues/26665, and it's been taken internally: https://github.com/Expensify/App/issues/26665#issuecomment-1775197275

This can be closed then.


RDPConf not supported winver 10.0.19044.2728

Hey all, geting an error on winver 19044.2728 (as stated in title lol). RDPConf showing version 10.0.19041.2673. I looked to see if there was a new ini for 19044.2728 but don't see one anywhere. Does anyone have the correct ini or can I get a build?

I'm going to attach a copy of termsrv.dll
termsrv.zip

Your version is 10.0.19041.2673

new ini for 19044.2728 but don't see one anywhere.

This is your Windows version. You need find INI with termsrv.dll version (avalible in RDPConf)

Duplicate of https://github.com/stascorp/rdpwrap/issues/2125


fix: don't bind cmd-1 to quick fixes (#500)

Hmm, it does fix the original issue, but I think of cmd-1 as quick fix. People who are used to that keybinding would be switching tabs when they wanted to show quick fixes...

hmm, right, difficult

@devoncarew I'd argue that web apps should avoid taking over expected browser behavior
... I hit the cmd-1 issue almost every time I use dartpad.

We ran into this exact same issue with Atom. Some group of developers expect quick-fix on cmd-1, some expect to switch tabs with it. There's not clear solution here -
I'll merge and we can see how that works for people -
Thanks for the PR @kasperpeulen!

Thanks. For browser apps, I think this is the best call.


Change license from CC-BY-SA to CC-BY

Motivation (discussion on the Carpentries mailing list): https://carpentries.topicbox.com/groups/discuss/Td64229aeb252a027
In short, the motivation is to simplify reuse for those who wish to take parts of our lessons and remix them into material which is CC-BY.
At the team meeting 2019-08-12 we have decided to change the license to CC-BY provided that all contributors to this lesson material agree to this change.
This issue will track the progress of this change.

@wikfeldt @annefou @Sabryr @blankdots can you please comment whether you agree to this change?

I agree to a license change to CC-BY.

I agree to a license change to CC-BY

@blankdots and @Sabryr do you agree to this change?

I agree to a license change to CC-BY

I Agree to this change!


Task ID 404's during Node Workflow

Hey all,
We're having an issue where we are running a workflow against a node to verify that we're using the right endpoints to publish and run a workflow. The intended flow for our testing purposes are:
PUT /api/2.0/workflows/graphs with workflow injectable name and workflow body.
POST /api/2.0/nodes/{id}/workflows with nodeID, and workflow request body.
the workflow is recognized in the RackHD API, and we can see from the output of on-tftp that there's an issue finding the taskID for a given task in our workflow.
An example of the output we see for a workflow:
0|on-taskg | [error] [2017-03-30T15:07:14.488Z] [on-taskgraph] [Task.Task] [Server] Task failed
0|on-taskg |  -> /node_modules/on-tasks/lib/task.js:346
0|on-taskg | error:          NotFoundError: Lookup Record Not Found (findOneByTerm)
0|on-taskg | taskId:         58de2e9a-7eff-4d3c-bb90-c29ed0f9fbb8
0|on-taskg | graphId:        fc1f9bc7-b3fe-4ca0-a25a-096887ea0ef9
0|on-taskg | injectableName: Task.Obm.Node.PxeBoot
0|on-taskg | node:           58dd1d30bbd977190806ad41
0|on-taskg | [info] [2017-03-30T15:07:14.508Z] [on-taskgraph] [TaskGraph.TaskRunner] [Server] Task finished

When we look up the taskID given, we can see that the task doesn't exist. The given graph id does specify the taskID shown, and the InjectableName exists in the task repository.
Wondering if this is a mongoDB timing issue of if there's a simple solution.
Note: The versions we intend to run this workflow on include from commit 6b895265545545264fc8583605f71492e35e6eaa to current master (2.0.0-rc to master), and we have the same problem throughout the releases and current commit.

Closing this out and replacing it with this RAC:
https://rackhd.atlassian.net/browse/RAC-4721


x/tools/cmd/goimports: weird behaviours - not importing and removing dependencies automatically

What version of Go are you using (go version)?

$ go version
go version go1.13 darwin/amd64

Does this issue reproduce with the latest release?
Yes, it does
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/brunoluiz/Library/Caches/go-build"
GOENV="/Users/brunoluiz/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/brunoluiz/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.13/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.13/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/brunoluiz/git/snapdiff/scheduler/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/46/73767m017_n8yfc849p52zpm0000gn/T/go-build095282659=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?
Using goimports -w file.go or through vim-go.
What did you expect to see?
Dependencies (external or internal) should be auto imported.
What did you see instead?
It doesn't auto-import packages from the same project/module, it doesn't fetch external packages and sometimes, even if I add import statements manually it scrapes it. Example: I am using strconv.itoa and even if I add strconv to imports statement, goimports removes it.
I thought initially it was a vim-go issue, but I've tried goimports -w file.go and it doesn't as expected.
Side note: if I run go get ..., it doesn't scrape the dependency.

I don't see anything suspicious in the provided go env output, and that's pretty much all there is to look at, so I have no idea what the problem is. Please provide a reproducer, or at least the output of goimports -v.

CC @matloob

I've re-tried now and it ?seems it works?, although vim-ale still struggles to find the external dependencies. Can gopls influence any of this?

Okay, I did some extra digging today. Basically, I have this mono-repo with all services for this project. If goimports is ran from the root, it leads to these weird stuff I've mentioned -- the same apply if I open vim in this folder.
When goimports is executed from ./service folder, then it works. Perhaps, if it is not in the root, it can't resolve the go.mod files from the sub-folders?

Yes, goimports uses all the same rules as the go command itself for module mode. You have GO111MODULE unset, so it sounds like you were getting goimports in GOPATH mode when running in the parent dir. That wouldn't work well unless you actually had your GOPATH populated with all your dependencies.

What would be the behaviour of goimports if my GO111MODULE was on instead of auto?

It will be able to find things that are in the module cache, but probably not much else, since it won't know what the import path of anything should be without knowing the module in use.
Closing, since there doesn't seem to be a bug here. For better or worse, most module-aware tools need to be run in the right working directory.


Subliminal version ?

Which version of subliminal is used ?
Latest version is 1.1.1 : https://github.com/Diaoul/subliminal/releases/tag/1.1.1

Version 0.8 is used.
For a more recent fork of this plugin, check https://github.com/pannal/Sub-Zero.bundle


Numeric extension outputs a bunch of console logging

Can that be removed?

@matthew-dean ,
Done.  That was my mistake.


Structured error types

Many applications of the interpreter can handle some error in a meaningful way (memory access violation, extern signatures mismatch, etc.), so it makes sense to encode them in other than a heap allocated string

I don't know the difference between this issue and https://github.com/paritytech/wasmi/issues/177 but the v1 implementation of wasmi (https://github.com/paritytech/wasmi/pull/287) now supports proper error types without usage of String internally. So this issue can be closed now.


Updates to balred() and gram()

balred() now supports "matchdc" and will handle unstable systems and will accept a list of ORDERS, which will return a list of reduced order systems. gram() now does Cholesky factored gramians if desired. Requires my updates to slycot.

Coverage decreased (-0.2%) to 75.797% when pulling f2bdde4cfcddea20f7c9052631cdf17d49c1d675 on mdclemen:master into cdd3e73838cea0b26a7155d0b2084aa698e5eefd on python-control:master.

In the first commit (https://github.com/python-control/python-control/pull/118/commits/cc4b5c75e676b86dd3ba16850c6a7361b0f30f0b) of this pull request, the message and author are incorrectly copied from cdd3e73838cea0b26a7155d0b2084aa698e5eefd. When I skim the diff, it appears that you applied changes as part of your own work, but then, those were combined with the patch corresponding to commit cdd3e73838cea0b26a7155d0b2084aa698e5eefd. Can you clean it up, in particular remove the re-applied pieces of commit cdd3e73838cea0b26a7155d0b2084aa698e5eefd?

It appears that substantial amounts of code are added in the first commit and then deleted or modified in the second. Can you add details in the commit messages to explain this transition? Alternatively, can you squash changes into a single commit?
Those are all of my questions and requests for now. I will wait until you respond or rebase before continuing to review.

I made changes to the code that you recommended, but my git skills might not be good enough for the other things you want me to do.

@mdclemen Can I have your permission to create a commit that has your changes from this PR and lists you as author (and me as committer)? This way I can make the rebasing adjustments that I requested above. If I do this, how do you prefer your name to be written? E.g., I can use "clementm" as in your commit https://github.com/python-control/python-control/pull/118/commits/f74e66552aa30645166f62fa4e5c115a196f85ca, or your name as it appears in your publications.
Alternatively, we can arrange to meet in IRC to work through the rebase process together.

In Accordance With
On Wed, Jan 18, 2017 at 2:30 PM, Scott C. Livingston <
<EMAIL_ADDRESS>wrote:

@slivingston commented on this pull request.
In control/modelsimp.py
https://github.com/python-control/python-control/pull/118#pullrequestreview-17342537
:

 """

 Balanced reduced order model of sys of a given order.
 States are eliminated based on Hankel singular value.

If sys has unstable modes, they are removed, the
balanced realization is done on the stable part, then
reinserted IAW reference below.

What is "IAW"?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/python-control/python-control/pull/118#pullrequestreview-17342537,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHIA6356Dhq1s6a8jG4dZMEYUEh2E077ks5rTpKTgaJpZM4KcvGY
.

I resolved the merge conflicts, but before I apply them here, can you first address my question about the description of the alpha parameter?

Should we keep the original call to AB09AD when the system is stable? Otherwise (if method='truncate' and the system is not stable), your newly introduced call to AB09MD is used.
The Fortran implementations of these two subroutines are different, so I am motivated to understand them more before removing the one dedicated to the case of stable systems.

Once we decide actions regarding AB09AD and the description of the alpha parameter, then this PR will be ready for merging. Thanks for your good work on the gram and balred functions!

I don't know why the SLICOT authors decided to include a user defined boundary for what constitutes unstable eigenvalues but essentially alpha allows the user to redefine the boundary for a stable eigenvalue.

@slivingston let me know what you think of my updates.

Your updates are good. Thanks for addressing my comments.


Move contact to new repo

https://github.com/podkrepi-bg/module-contact/issues also transferred the issues related to that module


Cannot move player object away from 0,0,0

This demo also suffers from the same issue I reported as a bug here -https://oculusdevelopers.zendesk.com/hc/en-us/requests/39022
Player object must stay at 0,0,0 or hands get offset incorrectly
You can see this by setting the player object to .2, 0,-2 for example.
I have had my support ticket open since June 23, 2022 17:01 with no further updates since initial contact

Hi @ibytergj, thank you for reporting this. This is an issue with the version of Interaction SDK used in the First Hand demo, and has since been resolved. The fix will be available in an upcoming Interaction SDK release.

Hello, I just downloaded release 43 from the Unity asset store and the fix is not in that version. Will you be able to tell me when we can expect the fix to ship?

@ibytergj Were you able to try with v44?  I think that is where this change was added.   Please let me know if this is still an issue, thanks!

Hi I did try this and it appears to be fixed. Thank you so much for
following up. The issue can be closed.
On Thu, Oct 27, 2022 at 4:20 PM kpfeifer-meta @.***>
wrote:

@ibytergj https://github.com/ibytergj Were you able to try with v44? I
think that is where this change was added. Please let me know if this is
still an issue, thanks!
—
Reply to this email directly, view it on GitHub
https://github.com/oculus-samples/Unity-FirstHand/issues/3#issuecomment-1294021171,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMNCURSE72YDXN3YFRXIHBTWFLP2FANCNFSM565PECZQ
.
You are receiving this because you were mentioned.Message ID:
@.***>


Random 0xfeff / ZERO WIDTH NO-BREAK SPACE being added to returned string values

This may be expected behavior I am not sure and cannot find any information about it. In some cases my protobuffer strings are returned with a ZERO WIDTH NO-BREAK SPACE.
`message Work {
Identifer id = 1;
WorkType work_type = 2;
string command = 3 [
(google.api.field_behavior) = OPTIONAL,
(grpc.gateway.protoc_gen_openapiv2.options.openapiv2_field) = {
title: "Work Request Command"
description: "Command to perform the work request."
}
];
}
node, err := a.srvClient.client.GetWork(ctx, &npb.GetWorkReq{Hardware: &npb.HardwareInfo{MacAddr: a.cfg.host.macAddr, IpAddr: a.cfg.host.ipAddrs}})
if err != nil {
return err
}
for _, cmd := range node.Work {
	switch cmd.WorkType {
	case npb.WorkType_INSTALL:
		if a.cfg.agent.mode == dev {
			//TODO FIX THE STUDDER (has to be fixed in ProtoFile)
			err = a.installPrimary(cmd.Id.Id, primaryDev)
			if err != nil {
				return err
			}
		} else {
			err = a.installPrimary(cmd.Id.Id, primary)
			if err != nil {
				return err
			}
		}
	case npb.WorkType_EXEC:
		cmdWithArgs := strings.Split(strings.TrimSpace(cmd.Command), " ")

		err = a.execCmd(cmd.Id.Id, cmdWithArgs[0], cmdWithArgs[1:]...)
		if err != nil {
			return err
		}
	default:
		//LOG BAD CMD TYPE
		//TODO LOG
		return fmt.Errorf("unknown work type: %s", cmd.WorkType)
	}`

I would expect cmd.Command to not contain random ZERO WIDTH NO-BREAK SPACE.
Any insights would be appreciated.

You haven’t provided any error messages or examples of the text containing a ZWNBSP or where in the string.
However, if this is happening at the start of your string, then this is probably a result of Byte-Order Marking, where a string starts with 0xfeff, and since 0xfffe is defined as an invalid Unicode codepoint, you can then identify if you’re dealing with UTF-16LE, from UTF-16BE. Especially, if it’s pulling this data from lines from a Windows text file, like .BAT as it is known to add these BOMs in files saved in Unicode.

Sorry for that missing information. The data is come from a MySQL select query. It is essentially has a gRPC api server that node.GetWork is calling and returning this.
I have confirmed that inside of the server it is not being added. It is being added some where in the encoding and transfer across the wire and then the subsequent decode on the client side.
Yes I have been able to work around it by specifically stripping the 0xfeff character from the string but it seems odd it is there in the first place.
I also agree that this is likely the result of Byte-Order Marking because it is at the very start of the string.
What I find most odd is that it only happens sometimes, it is not every string. It almost feels as if it is being used as padding for the encode/decode for the wire transfer but is not properly being stripped off in all cases.
I am happy to provide more detail or code or debug out put, I just was not sure what all would be helpful. Or if this was some known expected behavior I was not aware of.

Protobuf doesn’t typically use any padding let alone 0xfeff specifically.
Have you tried looking at the raw MySQL query values directly? Maybe someone is copy-pasting in from a Windows text file somewhere? It can be a notoriously difficult character to notice because it’s zero-width, and thus might not seem to show up normally.
Maybe a short copy of an encoded Work message that triggers the issue? I maybe wouldn’t jump straight to copy-pasting here an excerpt of the MySQL data for that message, but also, it probably wouldn’t hurt.


Using PdoDatabase?

Wow, this library looks great.  I'm curious if for a new project there are any reasons not to wrap the $db in a PdoDatabase::fromDsn class.
I started with this from the docs:
$db = new \Delight\Db\PdoDsn('pgsql:dbname=my-database;host=localhost;port=5432', 'my-username', 'my-password');
I wanted to insert something custom into user_profiles so I setup code like this and hoped to just use the existing connection to insert:
try { 	$user_data = array('id' => $userId, 'first_name' => $_POST['first_name'], 'last_name' => $_POST['last_name']); 	$db->insert('users_profiles', $user_data); } catch (Exception $e) { 	die('Invalid profile insert'); }
That threw a "Fatal error: Uncaught Error: Call to undefined method Delight\Db\PdoDsn::insert()" and I realized wrapping it in a PdoDatabase::fromDsn allows me to use the $db classes like $db->insert():
$db = \Delight\Db\PdoDatabase::fromDsn(new \Delight\Db\PdoDsn('pgsql:dbname=my-database;host=localhost;port=5432', 'my-username', 'my-password'));
So I guess I'm asking (1) why isn't that the preferred way and (2) is there anything dangerous about that on a new project?
Thanks.

Thank you!
There’s absolutely no difference between the two ways of creating or accessing the database instance, and thus nothing dangerous, either. In fact, if you only pass the configuration without creating the database instance yourself, the library will just create the instance in the next step – so the outcome is exactly the same. The only difference is whether you care about the database instance (and want to use it yourself) or just create it for this library.
But you made an excellent point: Given that many developers would like to use the database instance for something else as well, and given that there’s no downside (in particular with regard to performance or resource usage), the default should be changed. This has been done now: https://github.com/delight-im/PHP-Auth/commit/f5060b5a1d25b88b606268321762352d85fad5e1
Thanks again!

I'm developing this out and found an instance where FETCH_KEY_PAIR would be nice for a custom users table with a user options stored, and I didn't see KEY PAIR idea in the DB class.  I was wondering if you had a reason for not including that or anyone knew a better way to get key/value pairs from the DB class than just a foreach after the select like this:
$data = $db->select('SELECT id, val FROM users_custom_table WHERE user_id = ?', [$user_id]);
foreach ($data AS $row) {
	$profile['data'][$row['id']] = $row['val'];
}

Thanks again, and thanks for any ideas or tips,
Andrew

It seems this existing issue for the database component seems to address what you describe. It needs to be implemented in that component. But this should really be done shortly, as it’s an important and overdue feature.