Restrict live migration to single table-list and added guardrails for that around table-list flags #2354

priyanshi-yb · 2025-02-24T08:20:20Z

Describe the changes in this pull request

During resumption in the command export data from source we are now using the stored table list in MSR TableListExportedFromSource and SourceExportedTableListWithLeafPartitions based on the source type as for PostgreSQL source we allow filtering the leaf partitions as well so storing them in MSR.
In the command export data from target we are using the stored table list in MSR TableListExportedFromSource and then populate the leaf partitions from target for all the partitioned tables and then store it in the TargetExportedTableListWithLeafPartitions for further runs to avoid the fetching new leaf partitions from target.
Added guardrails around the table-list/ exclude-table-list flags for checking if there is any discrepancy in these on resumption compared to initial lists.
1. If any new tables are passed via these flags, commands error out saying Unknown tables found.
2. If any table-list changes are found, commands report them on the console output of the commands, like Missing tables ... / Extra tables found ... than the initial list and give a prompt to the user if they are fine to continue with the initial list, else abort the command and let them restart.
For the case of the partition, if any new leaf tables are added during the migration on the partitioned tables that are getting migrated. On resumption, we will report on the command output that some new leaf partitions found and will not be considered for the migration.

Describe if there are any user-facing changes

Yes, as mentioned above there will be user-facing changes for some guardrails around table-list etc.. now user won't be able to change the table-list during the live migration

Behaviour in these scenarios

New table is added on database either source/target -

With or without table-list flags: export data from source/target commands will be unaware of newly added tables and won’t consider it either during the run or re-run.
If a newly added table is passed through the table-list/exclude-table-list - commands error out saying unknown table, valid tables names are […].

➜ yb-voyager export data --export-dir ... --export-type snapshot-and-changes  --table-list test_partitions_quences                           
...
Continuing streaming from where we left off...
Unknown table names [test_partitions_quences] in the include list
Valid table names are: [public.foo_bar public.sales_region public.test_seq1 public.try public.sequence_check1 public.london public.sydney public.boston public.test_partitions_sequences_b public.test_partitions_sequences_l public.test_partitions_sequences_s public.sequence_check2 public.se..]

New leaf table is added on partitioned table in database either source/target -

With or without table-list flags:
-- During the run, export data from source/target commands will be unaware of newly added leaf tables and won’t consider it.
-- On re-run, export data from source/target commands will report to the user that new leaf tables are detected for partitioned tables with below msg -

Detected new partition tables for the following partitioned tables. These will not be considered during migration:
Root table: public.test_partitions_sequences, new leaf partitions: public.test_partitions_sequences_h
num tables to export: 1
table list for data export: [test_partitions_sequences (test_partitions_sequences_s)]

If new leaf partition table is passed through the table-list/exclude-table-list flags - commands error out saying unknown table, valid tables names are […].

➜  yb-voyager export data --export-dir .... --export-type snapshot-and-changes  --table-list test_partitions_sequences_h
....
Continuing streaming from where we left off...
Unknown table names [test_partitions_sequences_h] in the include list
Valid table names are: [public.foo_bar public.sales_region public.test_seq1 public.try public.sequence_check1 public.london public.sydney public.boston public.test_partitions_sequences_b public.test_partitions_sequences_l public.test_partitions_sequences_s public.sequence_check2 publi.....]

Table-list changes during resumption via flags

In case some tables are removed from the initial list in resumption - commands will report that there is discrepancy found and give prompt to user as mentioned below

  TARGET_DB_PASSWORD=*** yb-voyager export data from target --export-dir ... --table-list public."accounts_list_partitioned",public."empty_partition_table2",public."orders_interval_partition" --exclude-table-list empty_partition_table2
migrationID: 822cd9e3-00bc-4c7f-8d8c-195cdd3e24b7
Note: Live migration is a TECH PREVIEW feature.
export of data for source type as 'yugabytedb'
Continuing streaming from where we left off...
Changing the table list during live-migration is not allowed.
Missing tables in the current run compared to the initial list: empty_partition_table2_p_west,empty_partition_table2_p_east
Using the table list passed in the initial phase of migration - [public.accounts_list_partitioned_p_northwest .... public.orders_interval_partition_interval_partition_less_than_2018 public.orders_interval_partition]. 
Do you want continue?? [Y/N]: N
Aborting, Start a fresh migration...

In case some tables are added from the initial list in resumption - commands will report that there is discrepancy found and give prompt to user as mentioned below

 TARGET_DB_PASSWORD=*** yb-voyager export data from target --export-dir /home/centos/code/yb-voyager/migtests/tests/oracle/partitions/oracle_partitions_fallb_export-dir --table-list public."accounts_list_partitioned",public."empty_partition_table2",public."orders_interval_partition",empty_partition_table ...
migrationID: 822cd9e3-00bc-4c7f-8d8c-195cdd3e24b7
Note: Live migration is a TECH PREVIEW feature.
export of data for source type as 'yugabytedb'
Continuing streaming from where we left off...
Changing the table list during live-migration is not allowed.
Extra tables in the current run compared to the initial list: empty_partition_table2_p_extra,empty_partition_table_p_west,empty_partition_table_p_east,empty_partition_table
Using the table list passed in the initial phase of migration - [public.accounts_list_partitioned_p_northwest .... public.orders_interval_partition]. 
Do you want continue?? [Y/N]: Y
num tables to export: 3
table list for data export: [accounts_list_partitioned empty_partition_table2 orders_interval_partition]

How was this pull request tested?

Added unit tests with test container PG source for various cases.
Some TODOs remaining:

adding test assertions for below cases

validate guardrails check prompts
validate new leaf additions
Unknown table in table-list error exit

Does your PR have changes that can cause upgrade issues?

Component	Breaking changes?
MetaDB	No
Name registry json	No
Data File Descriptor Json	No
Export Snapshot Status Json	No
Import Data State	No
Export Status Json	No
Data .sql files of tables	No
Export and import data queue	No
Schema Dump	No
AssessmentDB	No
Sizing DB	o
Migration Assessment Report Json	No
Callhome Json	No
YugabyteD Tables	No
TargetDB Metadata Tables	No

…es on tables that are not part of migrations

… one

…ctName and then re-using the code to first check if it is leaf table else lookup

…ags storing list with leaf in msr directly

… msr new fields with nil etc..

makalaaneesh · 2025-02-26T10:30:49Z

yb-voyager/cmd/common.go

@@ -1040,6 +1040,9 @@ func storeTableListInMSR(tableList []sqlname.NameTuple) error {
 	}))
 	err := metaDB.UpdateMigrationStatusRecord(func(record *metadb.MigrationStatusRecord) {
 		record.TableListExportedFromSource = minQuotedTableList


nit: minQuotedTableList -> minQuotedTableListWithRoots

yb-voyager/cmd/exportData.go

makalaaneesh · 2025-02-26T10:53:04Z

yb-voyager/cmd/exportData.go

+	}
+
+	if len(lo.Keys(newLeafTables)) > 0 {
+		utils.PrintAndLog("Detected new partition tables for the following partitioned tables. These will not be considered during migration:")


Should we prompt?

Not sure if a prompt is required, I think there is nothing we want users to do here right? so this might just FYI?

makalaaneesh

Went over it at a high level, looks good!
Will give it a more detailed look soon along with the tests.

yb-voyager/cmd/exportData.go

… DDL changes on source, subsequent run with table-list/exclude-table-list flags. Some TODOs remaining to added assertions for

yb-voyager/cmd/exportData_test.go

makalaaneesh · 2025-02-27T15:43:45Z

yb-voyager/cmd/exportData_test.go

+
+	// getInitialTableList for subsequent run with  start-clean false and basic without table-list flags so no guardrails
+	startClean = false
+	getInitialTableistAndAssertExpectedResult(t, expectedTableList, expectedPartitionsToRootMap)


you added a new partition leaf above. This should error out no?

We are not errorring out in this case just reporting to the user that new leafs found for these root tables and these will not be considered during migration,

makalaaneesh · 2025-02-27T15:45:10Z

yb-voyager/cmd/exportData_test.go

+
+	getInitialTableistAndAssertExpectedResult(t, expectedTableList, expectedPartitionsToRootMap)
+
+	//case2: getInitialTableList for subsequent run with  start-clean false and basic with no table-list flags so no guardrails


If first run has table-list, and subsequent run does not have table-list, we should fail no?

We don't fail; we use the stored one directly. Not sure if we should fail or not. Maybe we can have a prompt in this case as well saying using the initial table list ...

…ls and new leafs addition. Added tests for subsequent run validating the guardrails of missing and extra tables and new leaf tables addition

…ion as a function variable to be able to override it in the test

…s by adding a new field in nameRegfor Sequences detemination

makalaaneesh · 2025-03-03T07:11:51Z

yb-voyager/cmd/exportData.go

@@ -552,12 +559,12 @@ func addLeafPartitionsInTableList(tableList []sqlname.NameTuple, ifTableListSet
 		allLeafPartitions := GetAllLeafPartitions(table)
 		prevLengthOfList := len(modifiedTableList)
 		switch true {
-		case len(allLeafPartitions) == 0 && rootTable != table: //leaf partition
+		case len(allLeafPartitions) == 0 && !rootTable.Equals(table): //leaf partition


Does our NameTuple.Equals work if the pointers are different, but the underlying values are the same?
Is that what prompted you to make this change?

Yes, it does the DeepEqual internally on the two nametuples.

makalaaneesh · 2025-03-03T07:15:43Z

yb-voyager/cmd/exportData.go

@@ -576,7 +583,12 @@ func addLeafPartitionsInTableList(tableList []sqlname.NameTuple, ifTableListSet
 func GetRootTableOfPartition(table sqlname.NameTuple) (sqlname.NameTuple, error) {
 	parentTable := source.DB().ParentTableOfPartition(table)
 	if parentTable == "" {
-		return table, nil
+		//now we know its a root table so return the tuple from the nameregistry


can you give more context in the comment on why you need to lookup from nameregistry again?
For my clarification: this is because the original tuples do not have the target-side of names, right?

Yes, right. The original tuples are hand-crafted ones without target names, so for the root, we shouldn't use these but instead get a proper one from the name registry.

makalaaneesh · 2025-03-03T07:23:48Z

yb-voyager/cmd/exportData.go

+	var err error
+	var includeTableList, excludeTableList []sqlname.NameTuple
+
+	applyFilterAndAddLeafTable := func(flagList string, flagName string) ([]sqlname.NameTuple, error) {


This structure of applying include/exclude is relatively easy to understand, thanks 👍

makalaaneesh · 2025-03-03T07:25:13Z

yb-voyager/cmd/exportData.go

 	} else {
-		tableList = fullTableList
+		//this is only for filtering the non-leaf and non-root tables - the mid level partitioned table from fullTableList


To remove non-leaf and non-root, you're still calling addLeafPartitionsInTableList? That sounds a bit weird. Does that function ignore all leafs, and then re-add them?

addLeafPartitionsInTableList has a boolean parameter addAllLeafPartitions in case this is false, that function will consider that the table-list passed is already exhaustive with all the tables (root, middle partition, leaf partitions, so on..) and it will just do the filtering to remove the middle level partitions and just the keep the leaf and root tables in the list.

makalaaneesh · 2025-03-03T07:29:11Z

yb-voyager/cmd/exportData.go

+		partitionsToRootTableMap = msr.TargetRenameTablesMap
+
+		//For the first run of export data from target we use the TableListExportedFromSource (which has only root tables)
+		if len(msr.TargetExportedTableListWithLeafPartitions) == 0 || msr.TargetRenameTablesMap == nil {


nit: create a variable for this since this is used below as well.

makalaaneesh · 2025-03-03T07:34:45Z

yb-voyager/cmd/exportData.go

+	})
+
+	// Finding all the partitions of all root tables part of migration, and report if there any new partitions added
+	rootToNewLeafTablesMap, err := detectNewLeafPartitionsOnPartitionedTables(rootTables, registeredList)


should we move this block below to where we are actually checking rootToNewLeafTablesMap and doing guardrails?

we use the rootToNewLeafTablesMap to calculate the currentList

makalaaneesh · 2025-03-03T07:35:41Z

yb-voyager/cmd/exportData.go

+		return nil, nil, fmt.Errorf("error applying table list flags for current list and remove roots: %v", err)
+	}
+
+	if len(lo.Keys(rootToNewLeafTablesMap)) > 0 {


shouldn't this check be done before the source.TableList == "" && source.ExcludeTableList == "" if block?

moved it in the detectNewLeafPartitionsOnPartitionedTable function back.

makalaaneesh · 2025-03-03T07:36:30Z

yb-voyager/cmd/exportData.go

+
+}
+
+func applyTableListFlagsOnCurrentAndRemoveRootsFromBothLists(registeredList []sqlname.NameTuple, tableListViaFlag string, excludeTableListViaFlag string, rootToNewLeafTablesMap map[string][]string, rootTables []sqlname.NameTuple, firstRunTableWithLeafsAndRoots []sqlname.NameTuple) ([]sqlname.NameTuple, []sqlname.NameTuple, error) {


nit: new lines for the args. Hard to read otherwise.

makalaaneesh · 2025-03-03T07:38:56Z

yb-voyager/src/namereg/namereg.go

 	return true, nil
 }

+func (reg *NameRegistry) GetRegisteredTableList() ([]*sqlname.ObjectName, error) {


add a comment here on why we implemented this (partitions)

makalaaneesh · 2025-03-03T07:41:06Z

yb-voyager/cmd/exportData_test.go

+	}
+}
+
+func fetchTableListFromSourceAndAssertResult(t *testing.T, expectedPartitionsToRootMap map[string]string, expectedTableList []sqlname.NameTuple) {


this is more like to assert that filtering is happening properly, right? maybe name it something like: assertTableListFiltering ?

makalaaneesh · 2025-03-03T07:41:46Z

yb-voyager/cmd/exportData_test.go

+	assert.Equal(t, len(diff), 0)
+}
+
+func getInitialTableistAndAssertExpectedResult(t *testing.T, expectedTableList []sqlname.NameTuple, expectedPartitionsToRootMap map[string]string) {


nit: would be good to have these function names start with assert.
assertInitialTableList

makalaaneesh · 2025-03-03T07:47:32Z

yb-voyager/cmd/exportData_test.go

+// Tests the unknown table case by over ridding the utils.ErrExit function to assert the error msg
+func testUnknownTableCaseForTableListFlags(t *testing.T, expectedUnknownErrorMsg string) {
+	previousFunction := utils.ErrExit
+	//changing the error exit function to test the unknown table scenario


oo, this does not seem like the best way to do it. To be fair, it essentially is just like "mocking" a function, so it's okay, but I think the right way would be:
If we write our functions in a way such that they return a list of guardrail failures, then we can just assert that, instead of having to mocking the errExit function.

Is this too much work given our current state?

It's not a lot of work. I think it's more of a choice between these ways -

Either we directly display the problem/guardrail and error out

Return as an error and then display it on the console eventually with the whole context.

e.g.

➜ yb-voyager export data ... --export-type snapshot-and-changes --table-list asdfa migrationID: a1194e55-3d95-4d37-95e3-d5221eed976d .... Unknown table names in the include list: [asdfa] Valid table names are: [...] ➜ yb-voyager export data ... --export-type snapshot-and-changes --table-list asdfa migrationID: a1194e55-3d95-4d37-95e3-d5221eed976d ... error getting initial table list: error applying table list flags for current list and remove roots: error in apply table list filter on registered list for the flags in current run: Unknown table names in the include list: [asdfa] Valid table names are: [...]

I think the first one is better, where we directly display the problem/guardrails because it's not an actual error per say.
Let me know what do you think?

makalaaneesh · 2025-03-03T07:48:53Z

yb-voyager/cmd/exportData_test.go

+	}
+	defer testPostgresSource.DB().Disconnect()
+	defer testPostgresSource.ExecuteSqls(cleanUpSqls...)
+	defer os.RemoveAll(fmt.Sprintf("%s/", testExportDir))


remove the sprintf? It's also a bit dangerous in case testExportDir is empty, cause then it will attempt to removeall("/")

makalaaneesh · 2025-03-03T07:50:28Z

yb-voyager/cmd/exportData_test.go

+		t.Errorf("error initialising name reg for the source: %v", err)
+	}
+	//Running the command level functions
+	source = *testPostgresSource.Source


why do you need to dereference here, a little confused? can't you directly use the pointer, and update the table-list, etc?

source (the global variable) is not a pointer type, so need to dereference here to assign the test source to the actual source variable that is used by the functions.

makalaaneesh · 2025-03-03T07:53:21Z

yb-voyager/cmd/exportData.go

+	}
+
+	if source.TableList == "" && source.ExcludeTableList == "" {
+		//which mean no table-lists are passed in subsequent runs


what if

in first run, user passed table-list

in subsequent run, user did not pass table-list
? Shouldn't we report the discrepancy ?

Hmm, okay let me remove this condition altogether and let the guardrails function do its of job of reporting the discrepancy.

makalaaneesh · 2025-03-03T07:54:46Z

yb-voyager/cmd/exportData_test.go

+	}
+
+	// getInitialTableList for subsequent run with  start-clean false and basic without table-list flags so no guardrails
+	startClean = false


let's make startClean a param of the getInitialTableistAndAssertExpectedResult func?

makalaaneesh · 2025-03-03T08:00:52Z

yb-voyager/cmd/exportData_test.go

+	assertGuardrailsChecksForMissingAndExtraTablesInSubsequentRun(t, expectedMissingTables2, expectedExtraTables2, firstRunTableList, rootTables)
+	getInitialTableistAndAssertExpectedResult(t, firstRunTableList, firstRunPartitionsToRootMap)
+
+	//case5: getInitialTableList for subsequent run with  start-clean false and basic with table-list and exclude-table-list flags


is passing both include and exclude list allowed today? i would have thought we should disallow it? in what situations does this help?

yes we allow that, it helps in scenario where:
tables on source - ab1,abc2,abc3,abc4,abc5, ..(few other tables)
table-list abc* (meaning all the abc prefixed tables)
exclude-table-list abc5 (excluding the abc5)

makalaaneesh · 2025-03-03T08:01:44Z

yb-voyager/cmd/exportData_test.go

+
+}
+
+func testCasesWithDifferentTableListFlagValuesTest1(t *testing.T, firstRunTableList []sqlname.NameTuple, firstRunPartitionsToRootMap map[string]string) {


nice different set of test-cases!
If/when Shubham finds some other cases, pls do add it here.

makalaaneesh · 2025-03-03T08:11:17Z

yb-voyager/cmd/exportData_test.go

+
+	assertGuardrailsChecksForMissingAndExtraTablesInSubsequentRun(t, expectedMissingTables4, expectedExtraTables4, firstRunTableList, rootTables)
+	getInitialTableistAndAssertExpectedResult(t, firstRunTableList, firstRunPartitionsToRootMap)
+}


test idea: ensure that
first run: foo* (foo1, foo2)
second run : foo1,foo2 does not result in any guardrails thrown.

yeah, I had it in mind for adding more tests around glob pattern support in the table list flags, will add it in a separate PR.

priyanshi-yb added 5 commits February 20, 2025 23:53

Initial changes for hanlding the table names for supporting ddl chang…

245034c

…es on tables that are not part of migrations

in case includetable list is not used then use stored list as include…

28736f3

… one

changed logic of getting getting registered list to first return obje…

0fe89a2

…ctName and then re-using the code to first check if it is leaf table else lookup

minor fix

81ebdc7

add leaf partititons in include list for guardrails

e07e69f

priyanshi-yb changed the title ~~Restrict live migration to single table-list from export data from source and guardrail for that around table-list flags~~ Restrict live migration to single table-list and guardrail for that around table-list flags Feb 24, 2025

handle the case where only subset of leaf partitions are passed in fl…

ce05787

…ags storing list with leaf in msr directly

priyanshi-yb force-pushed the priyanshi/name-reg-table-name branch from 850a85b to ce05787 Compare February 24, 2025 13:03

priyanshi-yb added 2 commits February 24, 2025 21:48

fix the export data from target case after testing

f275d35

minor cleanup

f09e16f

priyanshi-yb force-pushed the priyanshi/name-reg-table-name branch from bf3e4e0 to f09e16f Compare February 24, 2025 16:35

priyanshi-yb requested a review from makalaaneesh February 25, 2025 07:58

priyanshi-yb added 2 commits February 25, 2025 17:06

Report the new leaf tables added upfront on re-run in the command output

65fd658

minor cleanup

c760d92

priyanshi-yb marked this pull request as ready for review February 25, 2025 12:26

priyanshi-yb changed the title ~~Restrict live migration to single table-list and guardrail for that around table-list flags~~ Restrict live migration to single table-list and added guardrails for that around table-list flags Feb 25, 2025

Minor fix to handle upgrade and resumption in export data, hanlde the…

f8869de

… msr new fields with nil etc..

makalaaneesh reviewed Feb 26, 2025

View reviewed changes

priyanshi-yb added 2 commits February 27, 2025 00:00

restructured the code in smaller re-usable functions for table-list area

5da3738

minor change

2d132cb

priyanshi-yb requested a review from makalaaneesh February 27, 2025 07:27

minor misss for first run in export data from target

fa0370d

makalaaneesh reviewed Feb 27, 2025

View reviewed changes

yb-voyager/cmd/exportData.go Show resolved Hide resolved

yb-voyager/cmd/exportData.go Show resolved Hide resolved

yb-voyager/cmd/exportData.go Show resolved Hide resolved

priyanshi-yb added 5 commits February 27, 2025 17:53

added unit tests for fetchTablesNamesFromSourceAndFilterTableList

90e2dd7

fix git tag

36e02eb

clean db after each test

d042d3d

test for the subsequent run basic

bdd9b39

more tests on Subsequent run with basic start-clean true/false cases,…

e64f29f

… DDL changes on source, subsequent run with table-list/exclude-table-list flags. Some TODOs remaining to added assertions for

makalaaneesh reviewed Feb 27, 2025

View reviewed changes

Restructured the code a bit to be able to add more tests for guardrai…

b842a60

…ls and new leafs addition. Added tests for subsequent run validating the guardrails of missing and extra tables and new leaf tables addition

priyanshi-yb added 5 commits February 28, 2025 19:02

Added Unknown table case as well, by changing the utils.ErrExit funct…

25d97fc

…ion as a function variable to be able to override it in the test

Merge branch 'main' into priyanshi/name-reg-table-name

0cd8597

minor change

ccc7316

minor change

e4f8a89

fixed the 'GetRegisteredTableList' function to return only table name…

b034db2

…s by adding a new field in nameRegfor Sequences detemination

priyanshi-yb force-pushed the priyanshi/name-reg-table-name branch from 3ed77c3 to b034db2 Compare March 3, 2025 07:05

minor miss

51db76b

makalaaneesh reviewed Mar 3, 2025

View reviewed changes

priyanshi-yb added 2 commits March 3, 2025 14:56

some review comments

a61d355

minor comment

0325e8b


		getInitialTableistAndAssertExpectedResult(t, expectedTableList, expectedPartitionsToRootMap)

		//case2: getInitialTableList for subsequent run with start-clean false and basic with no table-list flags so no guardrails


		}

		func applyTableListFlagsOnCurrentAndRemoveRootsFromBothLists(registeredList []sqlname.NameTuple, tableListViaFlag string, excludeTableListViaFlag string, rootToNewLeafTablesMap map[string][]string, rootTables []sqlname.NameTuple, firstRunTableWithLeafsAndRoots []sqlname.NameTuple) ([]sqlname.NameTuple, []sqlname.NameTuple, error) {


		}

		func testCasesWithDifferentTableListFlagValuesTest1(t *testing.T, firstRunTableList []sqlname.NameTuple, firstRunPartitionsToRootMap map[string]string) {

Restrict live migration to single table-list and added guardrails for that around table-list flags #2354

Are you sure you want to change the base?

Restrict live migration to single table-list and added guardrails for that around table-list flags #2354

Conversation

priyanshi-yb commented Feb 24, 2025 • edited Loading

Describe the changes in this pull request

Describe if there are any user-facing changes

How was this pull request tested?

Does your PR have changes that can cause upgrade issues?

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

makalaaneesh left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

priyanshi-yb Mar 3, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

priyanshi-yb Mar 3, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

priyanshi-yb Mar 3, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

priyanshi-yb Mar 3, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

priyanshi-yb commented Feb 24, 2025 •

edited

Loading

priyanshi-yb Mar 3, 2025 •

edited

Loading

priyanshi-yb Mar 3, 2025 •

edited

Loading

priyanshi-yb Mar 3, 2025 •

edited

Loading

priyanshi-yb Mar 3, 2025 •

edited

Loading