Page MenuHomePhabricator
Differential D9710

[Flow202][lib][skip-ci] [18/23] Fix Flow issues in lib/socket
ClosedPublic
Actions

Authored by ashoat on Nov 4 2023, 12:05 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Apr 17, 8:36 PM
Unknown Object (File)
Thu, Apr 17, 7:40 PM
Unknown Object (File)
Thu, Apr 17, 6:39 AM
Unknown Object (File)
Mar 22 2025, 7:14 PM
Unknown Object (File)
Mar 22 2025, 11:08 AM
Unknown Object (File)
Mar 18 2025, 4:01 AM
Unknown Object (File)
Mar 18 2025, 4:01 AM
Unknown Object (File)
Mar 18 2025, 4:00 AM
View All 94 Files
Subscribers
tomek
will

Details

Reviewers
atul
Commits
rCOMM60cffd07793a: [Flow202][lib][skip-ci] [18/23] Fix Flow issues in lib/socket
Summary

These errors were mostly cases with React class components, where the new version of Flow wants a return type on every function defined in the class.

There were two exceptions:

  1. Flow didn't like us checking request.endpoint when request could be falsey, even though request was checked right before. Solved this by replacing the check with the optional chaining operator.
  2. In inflight-requests.js, Flow didn't like that we were checking the value of this.clearRequest before an await... Flow was afraid the value could change during the await. I fixed this by assigning the value to a local variable before checking it.
NOTE: CI will fail on this diff. I considered the possibility of fixing Flow errors BEFORE upgrading Flow, but it wasn't possible... in some cases, the fixes to support the new version of Flow caused errors in the old version. I could have hidden these type errors with $FlowFixMe lines and then later revert those, but that seemed like too much busy work.

Depends on D9709

Test Plan

Confirm the Flow errors go away

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

ashoat created this revision.Nov 4 2023, 12:05 PM
Herald added subscribers: will, tomek. · View Herald TranscriptNov 4 2023, 12:05 PM
ashoat added a child revision: D9711: [Flow202][lib][skip-ci] [19/23] Fix Flow issues in unparameterized Promise constructors.Nov 4 2023, 12:05 PM
Harbormaster returned this revision to the author for changes because remote builds failed.Nov 4 2023, 12:35 PM
Harbormaster failed remote builds in B23752: Diff 32714!
ashoat requested review of this revision.Nov 4 2023, 12:44 PM
atul accepted this revision.Nov 5 2023, 11:04 AM
This revision is now accepted and ready to land.Nov 5 2023, 11:04 AM
ashoat retitled this revision from [Flow202][lib] [18/23] Fix Flow issues in lib/socket to [Flow202][lib][skip-ci] [18/23] Fix Flow issues in lib/socket.Nov 19 2023, 3:04 PM
This revision was landed with ongoing or failed builds.Nov 27 2023, 3:25 PM
Closed by commit rCOMM60cffd07793a: [Flow202][lib][skip-ci] [18/23] Fix Flow issues in lib/socket (authored by ashoat). · Explain Why
This revision was automatically updated to reflect the committed changes.
ashoat added a commit: rCOMM60cffd07793a: [Flow202][lib][skip-ci] [18/23] Fix Flow issues in lib/socket.

Revision Contents
Changeset List

Diff 32714

View Options

lib/socket/api-request-handler.react.js

import ExpoModulesCore import ExpoModulesCore
import CryptoKit
public class AESCryptoModule: Module { public class AESCryptoModule: Module {
public func definition() -> ModuleDefinition { public func definition() -> ModuleDefinition {
Name("AESCrypto") Name("AESCrypto")
Function("hello") { () -> String in Function("generateKey", generateKey)
return "Hello world! 👋"
} }
} }
// MARK: - Function implementations
private func generateKey(destination: Uint8Array) throws {
let key = SymmetricKey(size: .bits256)
guard destination.byteLength * 8 == key.bitCount else {
throw InvalidKeyLengthException()
}
atulUnsubmitted
Not Done
Inline Actions

Before we even generate key via SymmetricKey, should we check that destination.byteLength is 32 and throw InvalidDestinationSizeException() if not?

It seems like destination is the input that we want to validate, so we should just do that directly? It's not really so much that SymmetricKey is giving us incorrect size key since it's (I'm assuming) always going to give us exactly the size we're asking for?

Feel free to re-request review if there's something I'm missing here.

atul: Before we even generate `key` via `SymmetricKey`, should we check that `destination.byteLength`…
bartekAuthorUnsubmitted
Done
Inline Actions

The only reason the guard is below SymmetricKey is that I wanted to use its bitCount property to get the desired destination length, but you're right that it can be done this way:

guard destination.byteLength == KEY_SIZE else {
  throw InvalidKeyLengthException()
}
let key = SymmetricKey(size: .bits256)

I'll refactor this as it is more clear solution

bartek: The only reason the guard is below `SymmetricKey` is that I wanted to use its `bitCount`…
key.withUnsafeBytes { bytes in
let _ = bytes.copyBytes(to: destination.rawBufferPtr())
}
}
// MARK: - Utilities
extension TypedArray {
func rawBufferPtr() -> UnsafeMutableRawBufferPointer {
UnsafeMutableRawBufferPointer(start: self.rawPointer,
count: self.byteLength)
}
}
// MARK: - Exception definitions
private class InvalidKeyLengthException: Exception {
override var reason: String {
"The AES key has invalid length"
}
} }
View Options

lib/socket/calendar-query-handler.react.js

import ExpoModulesCore import ExpoModulesCore
import CryptoKit
public class AESCryptoModule: Module { public class AESCryptoModule: Module {
public func definition() -> ModuleDefinition { public func definition() -> ModuleDefinition {
Name("AESCrypto") Name("AESCrypto")
Function("hello") { () -> String in Function("generateKey", generateKey)
return "Hello world! 👋"
} }
} }
// MARK: - Function implementations
private func generateKey(destination: Uint8Array) throws {
let key = SymmetricKey(size: .bits256)
guard destination.byteLength * 8 == key.bitCount else {
throw InvalidKeyLengthException()
}
atulUnsubmitted
Not Done
Inline Actions

Before we even generate key via SymmetricKey, should we check that destination.byteLength is 32 and throw InvalidDestinationSizeException() if not?

It seems like destination is the input that we want to validate, so we should just do that directly? It's not really so much that SymmetricKey is giving us incorrect size key since it's (I'm assuming) always going to give us exactly the size we're asking for?

Feel free to re-request review if there's something I'm missing here.

atul: Before we even generate `key` via `SymmetricKey`, should we check that `destination.byteLength`…
bartekAuthorUnsubmitted
Done
Inline Actions

The only reason the guard is below SymmetricKey is that I wanted to use its bitCount property to get the desired destination length, but you're right that it can be done this way:

guard destination.byteLength == KEY_SIZE else {
  throw InvalidKeyLengthException()
}
let key = SymmetricKey(size: .bits256)

I'll refactor this as it is more clear solution

bartek: The only reason the guard is below `SymmetricKey` is that I wanted to use its `bitCount`…
key.withUnsafeBytes { bytes in
let _ = bytes.copyBytes(to: destination.rawBufferPtr())
}
}
// MARK: - Utilities
extension TypedArray {
func rawBufferPtr() -> UnsafeMutableRawBufferPointer {
UnsafeMutableRawBufferPointer(start: self.rawPointer,
count: self.byteLength)
}
}
// MARK: - Exception definitions
private class InvalidKeyLengthException: Exception {
override var reason: String {
"The AES key has invalid length"
}
} }
View Options

lib/socket/inflight-requests.js

import ExpoModulesCore import ExpoModulesCore
import CryptoKit
public class AESCryptoModule: Module { public class AESCryptoModule: Module {
public func definition() -> ModuleDefinition { public func definition() -> ModuleDefinition {
Name("AESCrypto") Name("AESCrypto")
Function("hello") { () -> String in Function("generateKey", generateKey)
return "Hello world! 👋"
} }
} }
// MARK: - Function implementations
private func generateKey(destination: Uint8Array) throws {
let key = SymmetricKey(size: .bits256)
guard destination.byteLength * 8 == key.bitCount else {
throw InvalidKeyLengthException()
}
atulUnsubmitted
Not Done
Inline Actions

Before we even generate key via SymmetricKey, should we check that destination.byteLength is 32 and throw InvalidDestinationSizeException() if not?

It seems like destination is the input that we want to validate, so we should just do that directly? It's not really so much that SymmetricKey is giving us incorrect size key since it's (I'm assuming) always going to give us exactly the size we're asking for?

Feel free to re-request review if there's something I'm missing here.

atul: Before we even generate `key` via `SymmetricKey`, should we check that `destination.byteLength`…
bartekAuthorUnsubmitted
Done
Inline Actions

The only reason the guard is below SymmetricKey is that I wanted to use its bitCount property to get the desired destination length, but you're right that it can be done this way:

guard destination.byteLength == KEY_SIZE else {
  throw InvalidKeyLengthException()
}
let key = SymmetricKey(size: .bits256)

I'll refactor this as it is more clear solution

bartek: The only reason the guard is below `SymmetricKey` is that I wanted to use its `bitCount`…
key.withUnsafeBytes { bytes in
let _ = bytes.copyBytes(to: destination.rawBufferPtr())
}
}
// MARK: - Utilities
extension TypedArray {
func rawBufferPtr() -> UnsafeMutableRawBufferPointer {
UnsafeMutableRawBufferPointer(start: self.rawPointer,
count: self.byteLength)
}
}
// MARK: - Exception definitions
private class InvalidKeyLengthException: Exception {
override var reason: String {
"The AES key has invalid length"
}
} }
View Options

lib/socket/report-handler.react.js

import ExpoModulesCore import ExpoModulesCore
import CryptoKit
public class AESCryptoModule: Module { public class AESCryptoModule: Module {
public func definition() -> ModuleDefinition { public func definition() -> ModuleDefinition {
Name("AESCrypto") Name("AESCrypto")
Function("hello") { () -> String in Function("generateKey", generateKey)
return "Hello world! 👋"
} }
} }
// MARK: - Function implementations
private func generateKey(destination: Uint8Array) throws {
let key = SymmetricKey(size: .bits256)
guard destination.byteLength * 8 == key.bitCount else {
throw InvalidKeyLengthException()
}
atulUnsubmitted
Not Done
Inline Actions

Before we even generate key via SymmetricKey, should we check that destination.byteLength is 32 and throw InvalidDestinationSizeException() if not?

It seems like destination is the input that we want to validate, so we should just do that directly? It's not really so much that SymmetricKey is giving us incorrect size key since it's (I'm assuming) always going to give us exactly the size we're asking for?

Feel free to re-request review if there's something I'm missing here.

atul: Before we even generate `key` via `SymmetricKey`, should we check that `destination.byteLength`…
bartekAuthorUnsubmitted
Done
Inline Actions

The only reason the guard is below SymmetricKey is that I wanted to use its bitCount property to get the desired destination length, but you're right that it can be done this way:

guard destination.byteLength == KEY_SIZE else {
  throw InvalidKeyLengthException()
}
let key = SymmetricKey(size: .bits256)

I'll refactor this as it is more clear solution

bartek: The only reason the guard is below `SymmetricKey` is that I wanted to use its `bitCount`…
key.withUnsafeBytes { bytes in
let _ = bytes.copyBytes(to: destination.rawBufferPtr())
}
}
// MARK: - Utilities
extension TypedArray {
func rawBufferPtr() -> UnsafeMutableRawBufferPointer {
UnsafeMutableRawBufferPointer(start: self.rawPointer,
count: self.byteLength)
}
}
// MARK: - Exception definitions
private class InvalidKeyLengthException: Exception {
override var reason: String {
"The AES key has invalid length"
}
} }
View Options

lib/socket/request-response-handler.react.js

Loading...